How to tell apart different exception types in BackgroundWorker.RunWorkerCompleted event handler

Question

I am doing little hobby project in C#, a language I do not know well, and have stumbled upon the following:

Suppose you have an asynchronous operation implemented by using BackgroundWorker. Now if there is an exception, event RunWorkerCompleted will be raised and RunWorkerCompletedEventArgs.Error will be non-null.

Is the following the canonical way then to handle different exception types? (Here all the exception kinds are siblings WRT inheritance)

if (e.Error != null)
{
    FirstKindOfException e1 = e as OneKindOfException;
    SecondKindOfException e2 = e as SecondKindOfException;
    ...
    LastKindOfException en = e as LastKindOfException;
    if (e1 != null)
    {
        ...
    }
    else if (e2 != null)
    {
        ...
    }
    ...
    else
    {
        ...
    }
}

It works, but... it doesn't feel right.

Answer 1

Using is operator maybe?

if (e is OneKindOfException)
{
}
else if (e is SecondKindOfException)
{
}

Answer 2

Use the is operator:

if (e.Error is FirstKindOfException) {
   //...
}
else if (e.Error is SecondKindOfException) {
   //...
}
//etc..

Or just cut it short since you don't know how to handle these exceptions anyway. If you did then you would have caught them in the DoWork() event handler, there's no point in trying to handle them after the state has evaporated:

if (e.Error != null) throw new BackgroundTaskFailedException(e.Error);

Answer 3

Yes, you can do this but really depends what you are going to do with all those exception types. Normally this will only be shown to the user so there is no need to check the type of the error.

Also you need to keep in mind that it is likely the type of the exception could be AggregateException - which is return from the Task<T> operations - so you need to be carefull.

Answer 4

You could use is to keep each test tightly scoped:

if (e.Error is FirstKindOfException )
{
    ...
}
else if (e.Error is SecondKindOfException)
{
    ...
}

(then re-cast if you want special values from the exception)

To be honest, though, it is pretty rare that I need to handle lots of different types of exceptions. In most cases, it is fine to simply recover (compensate) to a known state and report the error appropriately. Generally I prefer to test for likely errors before I start the action, so an exception truly is something exceptional.