Introduction

BackgroundWorker does not make exceptions disappear. If code inside DoWork throws, the failure is captured and surfaced through the completion event. If you ignore that error path, the application may look like the worker “failed silently” or crashed unpredictably depending on where the exception escaped.

How Exceptions Travel Through BackgroundWorker

The normal event flow is:

• 'DoWork'
• optional ProgressChanged
• 'RunWorkerCompleted'

If an exception is thrown in DoWork, BackgroundWorker catches it and places it in RunWorkerCompletedEventArgs.Error. That means the correct place to inspect worker failures is often the completion handler, not only a local try-catch inside the worker body.

A Safe Basic Pattern

Here is a minimal example:

1using System;
2using System.ComponentModel;
3
4class Program
5{
6    static void Main()
7    {
8        var worker = new BackgroundWorker();
9
10        worker.DoWork += (sender, e) =>
11        {
12            throw new InvalidOperationException("Something went wrong in the background task.");
13        };
14
15        worker.RunWorkerCompleted += (sender, e) =>
16        {
17            if (e.Error != null)
18            {
19                Console.WriteLine("Worker failed: " + e.Error.Message);
20                return;
21            }
22
23            Console.WriteLine("Worker completed successfully.");
24        };
25
26        worker.RunWorkerAsync();
27        Console.ReadLine();
28    }
29}

This makes the failure visible and keeps the application in control of how it responds.

When to Catch Inside DoWork

Sometimes it still makes sense to catch inside DoWork, especially if you want to translate exceptions into a custom result or perform cleanup close to the failing operation:

1worker.DoWork += (sender, e) =>
2{
3    try
4    {
5        // risky background work
6        e.Result = DoExpensiveOperation();
7    }
8    catch (Exception ex)
9    {
10        e.Result = null;
11        throw new ApplicationException("Background operation failed.", ex);
12    }
13};

Even here, the final reporting still happens through RunWorkerCompleted, because that is where the UI thread usually learns whether the background operation succeeded.

Exceptions in Other Events Behave Differently

This is a subtle but important point. Exceptions thrown in DoWork are captured and routed into e.Error. Exceptions thrown in ProgressChanged or RunWorkerCompleted are different because those handlers run on the thread that created the worker, often the UI thread in desktop apps.

If you throw there and do not handle it, you can still crash the application in the usual UI-thread way.

So the exception model is:

• 'DoWork: error captured and passed to completion event'
• 'ProgressChanged and RunWorkerCompleted: normal UI-thread exception behavior'

Cancellation Is Not an Error

If the worker supports cancellation, do not confuse cancellation with failure. Check e.Cancelled separately:

1worker.WorkerSupportsCancellation = true;
2
3worker.RunWorkerCompleted += (sender, e) =>
4{
5    if (e.Cancelled)
6    {
7        Console.WriteLine("Worker was cancelled.");
8    }
9    else if (e.Error != null)
10    {
11        Console.WriteLine("Worker failed: " + e.Error.Message);
12    }
13    else
14    {
15        Console.WriteLine("Worker result: " + e.Result);
16    }
17};

This keeps the success, cancellation, and failure paths distinct.

BackgroundWorker Is Legacy but Still Common

Modern .NET code often prefers Task, async, and await, but BackgroundWorker still appears in older WinForms and WPF applications. If you are maintaining that code, the key is to treat the completion event as the place where background exceptions are observed and turned into user-visible behavior.

That is usually enough to make the old pattern reliable even if you are not rewriting it immediately.

Common Pitfalls

The most common mistake is assuming an exception thrown inside DoWork will automatically show up where the worker was started. It will not. You need to inspect RunWorkerCompletedEventArgs.Error.

Another pitfall is handling only the success path in RunWorkerCompleted and ignoring e.Error and e.Cancelled. That makes failures look mysterious even though the framework actually delivered the error information.

It is also easy to forget that exceptions thrown in ProgressChanged or RunWorkerCompleted are not wrapped the same way. Those handlers can still crash the UI thread if you let exceptions escape.

Finally, if the application is heavily asynchronous already, consider whether BackgroundWorker should be kept at all. It still works, but newer task-based patterns are usually easier to compose and test.

Summary

• Exceptions thrown in DoWork are captured and exposed through RunWorkerCompletedEventArgs.Error.
• Check e.Error, e.Cancelled, and e.Result separately in the completion handler.
• Exceptions in ProgressChanged and RunWorkerCompleted behave like ordinary UI-thread exceptions.
• Use local try-catch in DoWork only when you need cleanup or custom wrapping, not as a substitute for completion handling.
• 'BackgroundWorker is legacy, but its error model is manageable once you handle completion correctly.'