Using statement and try-catch()-finally repetition?
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
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).