Question

The using(…) statement is syntactic sugar for try{} finally {}.

But if I then have a using statement like below:

using (FileStream fs = File.Open(path))
{


}

Now I want to catch the exceptions that opening this file could cause (and this is fairly high risk code in that it can fail due to the environment), but if I write try-catch inside would that not be repetition? When the code gets compiled to IL, I assume the repetition will get deleted when the code is JITted?

However, I would want to catch the exceptions opening a file can cause (so I should wrap the try-catch outside the using statement’s scope), and also the exceptions for whatever I do inside the using block so I should add the try-catch inside the block.

This seems like I am adding a lot of repetition to what the CLR probably does inside. Does the CLR add catch clauses?

My colleague argued that a using statement is messy (but this was because a single line was slightly long due to me hard coding them as I needed to change them very quickly and didn’t have access to other parts of the code base). Said colleague doesn’t use the using statement but is there ever any functional difference between the using statement and try-finally/try-catch-finally? I did see one case of this where WCF services have a not well known corner case about using finally and returning values (something about finally). The solution was to use a check block. Is there anything like this in C#?

On another note, are all types which implement IDisposale owners of unmanaged resources? A discussion with my friend pointed the answer to being no. (I have also read some threads in the using section of this forum, some very good knowledge there).

Answer 1

You can implement the pattern yourself if you need to handle some exceptions if you really want to. Personally, I still find it simpler (and more importantly, clearer) to just wrap the using in try/catch block.

But if you do it yourself, make sure you get it right. The Using block also creates an anonymous scope block so that your variable becomes eligible for collection sooner. The .Dispose() method that’s called at the end of the Using block only cleans up unmanaged resources, and so any memory your object holds may hang around a little longer. It’s not likely a huge concern, but it is worth remembering just in case.

So, to do a direct adaption of the pattern, your code needs to look more like this:

{
    FileStream fs;
    try
    {
        fs = File.Open(path);

    }
    catch (FileNotFoundException e) { /* ... */ }
    catch (IOException e) { /* ... */ }
    catch (Exception e) {/* ... */}
    finally
    {
        if (fs != null) fs.Dispose();
    }
}

Personally, I’d like to see Using expanded to support Catch and Finally blocks. Since they’re already performing a transformation on the code, it doesn’t seem like this would add that much additional complexity.