Question

The using statement doesn’t capture exceptions. To catch exceptions you have two choices:

1) Unwrap the using and implement it manually:

void MyFunc()
{
    StreamReader myReader = null;

    try
    {
        myReader = new StreamReader(path);
        //use myReader
    }
    catch (Exception e)
    {
        //do something with exception
    }
    finally
    {
        if (myReader != null)
            myReader.Dispose();
    }
}

or 2) keep the using, and wrap it in another try catch block

void MyFunc()
{
    try
    {
        using (StreamReader myReader = new StreamReader(path))
        {
             //use myReader
        }
    }
    catch (Exception e)
    {
        //do something with exception
    }
}

To me the second one looks neater, especially when you having multiple using statements, because it describes the flow better, and removes the explicit declarations, null checks and Dispose() calls.

However, it feels wrong due to the extra try catch overhead which effectively redundant.

What’s the standard practice?

Answer 1

The overhead of exception handling constructions is just metadata. There is no runtime performance overhead if no exception gets thrown. Unlike some other runtimes entering/leaving an exception handling clause is free in .net. When an exception is thrown the runtime uses the metadata and the current instruction-pointer to figure out which handling clauses to execute.

I favor the second one. Releasing resources and handling exceptions are separate concepts, so it’s only natural for them to be separate in code.