使用statement和try-catch（） - 最后重复？

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

My preference would be to keep the using statement and wrap it in a try/catch. The outer try/catch will catch whatever exceptions you need to watch for, while ignoring the Dispose(). This has the added advantage of protecting you from yourself should you refactor this later to move the try/catch elsewhere (like in a calling function).

As far as your question about IDisposable: Anyone can implement this for any reason they like. There is no technical reason for it to be limited to unmanaged resources. (Whether or not it should be limited to unmanaged resources in your code is a different question).

Answer 2

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.

Answer 3

If you need to explicitly handle different exceptional cases which may happen during the statement, you could replace using with try/catch/finally and call Dispose() explicitly in the finally. Or you could put a try/catch around the using block to separate exceptional circumstances from ensuring disposal.

The only thing using does is ensure Dispose() is called even if an exception is thrown inside the block. That is a very limited, highly specific implementation of the general try/[catch]/finally structure.

The important thing is that none of these options have any real impact - as long as it does what you need, is readable and understandable, who cares? It's not like an extra try will be a bottleneck or anything!

To answer your last question - no, IDisposable definitely does not necessarily mean the implementer has handles to unmanaged resources. It's a far simpler and more generic pattern than that. Here's one useful example:

public class Timer : IDisposable
{
    internal Stopwatch _stopwatch;
    public Timer()
    {
        this._stopwatch = new Stopwatch();
        this._stopwatch.Start();
    }

    public void Dispose()
    {
        this._stopwatch.Stop();
    }
}

We can use this to time things without having to explicitly rely on start and stop being called by using:

using(Timer timer = new Timer())
{
    //do stuff
}

Answer 4

The biggest difference between using and try-finally is that using will only call the Dispose() method. If you implement your own finally block can do other logic, for example logging, which would not be included in the using.

Answer 5

The using construct is shorthand for a try/finally block. That is, the compiler generates:

FileStream fs = null;
try
{
    fs = File.Open(path);
    // ...
}
finally
{
    if (fs != null)
        fs.Dispose();
}

So it is proper to use using if you do not need a catch , but if you do then you should just use a normal try/catch/finally .