views:

1429

answers:

11
+11  Q: 

C# "Using" Syntax

Does the using catch the exception or throw it? i.e.

using (StreamReader rdr = File.OpenText("file.txt"))
{
 //do stuff
}

If the streamreader throws an exception is it caught by using or thrown so the calling function can handle it?

A: 

It is thrown.

MagicKat
+1  A: 

If you don't specifically catch an exception it's thrown up the stack until something does

hometoast
+5  A: 

using allows the exception to boil through. It acts like a try/finally, where the finally disposes the used object. Thus, it is only appropriate/useful for objects that implement IDisposable.

Chris Marasti-Georg
+11  A: 

using statements do not eat exceptions.

All "Using" does is scope your object to the using block, and automatically calls Dispose() on the object when it leaves the block.

There is a gotcha though, if a thread is forcefully aborted by an outside source, it is possible that Dispose will never be called.

FlySwat
I am fairly certain that your "gotcha" is not accurate. Since the StreamReader class implements IDisposable, the using statement will take care of the disposal of the object. Because the using statement acts like a finally block, it doesn't matter if you have an exception or return.
Brendan Enrick
According to http://msdn.microsoft.com/en-us/library/system.threading.threadabortexception.aspx , catch and finally statements are still executed. Since "using" compiles as a finally block, the stread reader in your example will be disposed.
Uhall
I would concur with the previous two comments. In addition to @Uhall's comment above, the ThreadAbortException does not abort the thread, it just catches the exception that is raised as a result.
Lloyd Cotten
Quite right...it only happens if the thread is forcefully aborted, not when throwing the exception. Updating the answer.
FlySwat
+2  A: 

The using does not interfere with exception handling apart from cleaning up stuff in its scope.

It doesn't handle exceptions but lets exceptions pass through.

tpower
A: 

"using" does not catch exceptions, it just disposes of resources in the event of unhandled exceptions.

Perhaps the question is, would it dispose of resources allocated in the parentheses if an error also occured in the declaration? It's hard to imagine both happening, though.

harpo
+23  A: 

When you see a using statement, think of this code:

StreadReader rdr;
try
{
    rdr = File.OpenText("file.txt");
    //do stuff
}
finally
{
    rdr.Dispose();
}

So the real answer is that it doesn't do anything with the exception thrown in the body of the using block. It doesn't handle it or rethrow it.

jop
+2  A: 

It throws the exception, so either your containing method needs to handle it, or pass it up the stack.

try
{
    using (
        StreamReader rdr = File.OpenText("file.txt"))
    { //do stuff 
    }
}
catch (FileNotFoundException Ex)
{
    // The file didn't exist
}
catch (AccessViolationException Ex)
{
    // You don't have the permission to open this
}
catch (Exception Ex)
{
    // Something happened! 
}
stephenbayer
+1  A: 

using guarantees* the object created will be disposed at the end of the block, even if an exception is thrown. The exception is not caught. However, you need to be careful about what you do if you try to catch it yourself. Since any code that catches the exception is outside the scope block defined by the using statement, your object won't be available to that code.

*barring the usual suspects like power failure, nuclear holocaust, etc

Joel Coehoorn
A: 

You can imagine using as a try...finally block without the catch block. In the finally block, IDisposable.Dispose is called, and since there is no catch block, any exceptions are thrown up the stack.

petr k.
+2  A: 

Any exceptions that are thrown in the initialization expression of the using statement will propagate up the method scope and call stack as expected.

One thing to watch out for, though, is that if an exception occures in the initialization expression, then the Dispose() method will not be called on the expression variable. This is almost always the behavior that you would want, since you don't want to bother disposing an object that was not actually created. However, there could be an issue in complex circumstances. That is, if multiple initializations are buried inside the constructor and some succeed prior to the exception being thrown, then the Dispose call may not occur at that point. This is usually not a problem, though, since constructors are usually kept simple.

Jeffrey L Whitledge
This is *always* the behavior you want. If multiple initializations are buried inside the constructor, it's up to the constructor to manage any necessary cleanup. No outside code could possibly do so, as the object won't actually be created.
Joe
@Joe - I'm trying to sound smart here. Stop pointing out the flaws in my logic!
Jeffrey L Whitledge