How to avoid exceptions catches copy-paste in .NET

Question

Working with .NET framework I have a service with a set of methods that can generates several types of exceptions: MyException2, MyExc1, Exception... To provide proper work for all methods, each of them contains following sections:

[WebMethod]
void Method1(...)
{
    try
    {
        ... required functionality
    }
    catch(MyException2 exc)
    {
        ... process exception of MyException2 type
    }
    catch(MyExc1 exc)
    {
        ... process exception of MyExc1 type
    }
    catch(Exception exc)
    {
        ... process exception of Exception type
    }
    ... process and return result if necessary
}

It is very boring to have exactly same stuff in EACH service method (each method has different set of parameters) with exactly same exceptions processing functionality...

Is there any possibility to "group" these catch-sections and use only one line (something similar to C++ macros)? Probably something new in .NET 4.0 is related to this topic?

Thanks.

P.S. Any thoughts are welcome.

Answer 1

If the exception handling is exactly the same in all of your methods, you could do something like:

void CallService(Action method)
{
    try
    {
        // Execute method
        method();
    }
    catch(MyException2 exc)
    {
        ... process exception of MyException2 type
    }
    catch(MyExc1 exc)
    {   
        ... process exception of MyExc1 type
    }
    catch(Exception exc)
    {
        ... process exception of Exception type
    }
}

Then, you could just rewrite your client code to do:

int i = 3;
string arg = "Foo";
this.CallService( () => this.Method1(i) );
this.CallService( () => this.Method2(arg, 5) );

This allows your Method1 and Method2 methods to be simply:

void Method1(int arg)
{
    // Leave out exception handling here...
    ... required functionality  
    ... process and return result if necessary
}

void Method2(string stringArg, int intArg)
{
    // Leave out exception handling here...
    ... required functionality  
    ... process and return result if necessary
}

Answer 2

I know it's bad practice, but if you have the exact same error handling in each catch statement, when why not just use the last catch statement as a catch all?

This of course assumes all your exceptions inherit from Exception.

Answer 3

Why not just factor the code into a helper method to do it for you (you can add whatever new exceptions you need in the future to HandleException as well, which makes it quite scalable)?

try
{
    ... required functionality
}
catch (Exception e)
{
    HandleException(e);
    throw; // only if you need the exception to propagate to caller
}


private void HandleException(Exception e)
{
    if (e is MyException2)
    {
        ... process exception of MyException2 type
    }
    else if (e is MyExc1)
    {
        ... process exception of MyExc1 type
    }
    else
    {
        ... process exception of Exception type
    }
}

Answer 4

I'd look closely at what you're doing to "process" these exceptions. There's a good chance that you don't need the catch blocks at all, and that you should be permitting the exceptions to propagate.

Answer 5

In a sudden flash of geekiness (and to show what you could but most probably should not and do not want to do): You can make the whole thing more composable and reusable by generating functions on the fly that contain the exception handling logic:

static class ExceptionHandlerExtensionMethods 
{
    // extend to Func<T> as desired
    public static Action Catching<T>(this Action what, Action<T> handler) 
        where T : Exception
    {
        return () =>
        {
             try
             {
                 what();
             }
             catch (T ex)
             {
                 handler(ex);
             }
         };
    }
}

Now you can implement and reuse exception-type specific handler functions somewhere, and compose them into the exception handling of some other method.

To remove the redundancy, you can write a helper function that adds the "typical" exception handler functions to what ever you want to call and call this decorated method instead.

Answer 6

Using the CallService method from Reed Copsey:

void DoSomething(object param1, int param2)
{
    this.CallService(() =>
    {
         // work with param1 and param2 here
    }
}

For the cases when you need to return a value, you might have to duplicate CallService to return a type parameter.

T CallService<T>(Func<T> callback) { /* ... */ }

Answer 7

I've done the following in a similar situation. I'll show the technique in two steps...

---

Step 1. Create a method that provides a specific execution context for other code:

// this static method is responsible for setting up a context for other code
// to run in; specifically, it provides the exception handling "plumbing":
public static void guarded(Action action)
{                      //  ^^^^^^^^^^^^^
    try                //  actual code to be executed
    {
        action();
    }
    catch (SomeExceptionA ea)
    {
        // handle exception...
    }
    catch (SomeExceptionB eb)
    {
        // handle exception...
    }
    // etc.
}

---

Step 2. Apply this context to any piece of code:

Next, you simply "wrap" this exception handling around the actual code in your methods:

public void MethodA()
{
    guarded(() =>   // <-- wrap the execution handlers around the following code:
    {
        // do something which might throw an exception...
    });
}

public void MethodB()
{
    guarded(() =>
    {
        // do something which might throw an exception...
    });
}

---

Summary:

The general idea here is to write a function (guarded in the above example) that sets up a specific execution context for other code to run in. (The context in this example is providing exception handling.) The code that is to be executed in this context is provided as a lambda function. You could even adapt the context-creating function so that the code in the lambda function can return a value.