Catching exeptions in a using {} sttatement

I'm wondering what the prefered method of handling exceptions is in a using statement would be.

For example, last I checked you cant use an object that has already been initialized in a using statement (though some examples in this forum indicate differently, so I could be wrong on this)...

So, this

Sometype X;

try
       {
         ...get un-reliable object X
       }
catch
       {
         ...
       }

using (X)
      {
         ...
       }

,,,wont work.

When the using statement initializes the var, the CLR generated MSIL places the initialization before the try block (for probable good reason that I'm at present unsure of),,, so an error will throw an exception, and it seems as if you'd need to use some syntax like this:

try { using(something) { ... } } catch { .... }

Am I missing something, is that just the way it is, as I haven't read too much that mentions exceptions that occur (...and w/ the type of objects that get created in a using statement, database connections, streams, etc--- are subject to uncontrolable exceptions...) in the using statement.

Thanks.

Answer this question

Catching exeptions in a using {} sttatement

DBA2

Blair Allen Stark wrote:
This requires that any error in the constructor of MyComponent be handled to clear up any internally allocated resources and the exception should be rethrown. this will "bubble the exception" up to a point that isnt in the Using scope which is proper, because we never got a component (the constructor failed) and therefore the component was never allocated and never used.
make sense

It makes sense to me--- but it still seems as if you need to put in some code somewhere that will handle an exception in the constructor. The resource is null, so it never was allocated, but something like

using ( WebClient client = new Webclient )
using ( Stream stream = client.OpenRead(http://some-bad-address.com) )
{

}

Both WebClient + stream have dispose, so--- client is allocated and released (or it should be--- with the exception in the next line, I'm unsure---), stream throws an exception because it can't reach "some-bad-address" so you have to deal w/ that. It Seems to be exactly what I had said previously.

-m.

Zeb Macahan

Blair Allen Stark wrote:

stream doesnt throw the exception, client threw an exception during OpenRead, therefore stream was never allocated and returned
You're right, my mistake--- The rest all is how I imagined it, though--- for clarity's sake I'll probably put the try/catch further up in code that calls the method that has the using statement.

Thanks for your input.
SG2005
typically the pattern is
1. Allocate Resources
2. Try to use resources
3. Catch error caused by resources
4. finally free resource
if the error occurs at 1, the resources arent allocated (or at least resources internal to rthe requested resource should be properly released as part of the internal allocation exception handling)
so -

using (IComponent component as new MyComponent()) // 1. Allocate Resources
{
try
{
// 2. Try to use resources
}
catch(Exception ex)
{
// 3. Catch error caused by resources
}
} // 4. finally free resource
// (NOTE: THIS IS IMPLICIT DUE TO THE USING CLAUSE!!!)

This requires that any error in the constructor of MyComponent be handled to clear up any internally allocated resources and the exception should be rethrown. this will "bubble the exception" up to a point that isnt in the Using scope which is proper, because we never got a component (the constructor failed) and therefore the component was never allocated and never used.

make sense
Mustafa AYG&#220;N

stream doesnt throw the exception, client threw an exception during OpenRead, therefore stream was never allocated and returned

using ( WebClient client = new Webclient )
{
// 1 we have a client
using ( Stream stream = client.OpenRead(http://some-bad-address.com) )
{
// 2 we have a client and stream
}
// 3 we have no stream but we have client
}
// 4 we have no client or stream
DavidR100
A common pattern is to have the try/catch outside the using block, such as:

try
{
using (IComponent component as new MyComponent()) // 1. Allocate Resources
{
// 2. Try to use resources
} // 3. finally free resource
}
catch(Exception ex)
{
// 4. Catch error caused by resources
}

Or more realistically, the try/catch may be in a different method further up the call stack. In this case, you have no problems with exceptions thrown by the constructor or with multiple using blocks.
Catching exeptions in a using {} sttatement

Answer this question