Why did Msoft implement try/catch this way?

  • Thread starter Thread starter ChrisB
  • Start date Start date
C

ChrisB

Hello All:

I notice that when using try/catch blocks in C#, variables declared in the
try block go out of scope in the finally block.

So, for example, the following code generates a compiler error:

try
{
SqlDataReader sqlDataReader = new SqlDataReader(sqlConnection,
CommandType.StoredProcedure, "ConsumerGet", consumerParameters));

// other code
}
finally
{
sqlDataReader.Close() // make sure reader is closed; generates out of
scope error
}


Would it not have been preferable to make objects declared try blocks
accessible in their corresponding finally block. Is there a benefit to this
retriction that I am missing?

Thanks,
Chris
 
Isn't this true for all code blocks.
{} is a code block and variables declared within are local to that code
block.
 
ChrisB said:
I notice that when using try/catch blocks in C#, variables declared in the
try block go out of scope in the finally block.

So, for example, the following code generates a compiler error:

try
{
SqlDataReader sqlDataReader = new SqlDataReader(sqlConnection,
CommandType.StoredProcedure, "ConsumerGet", consumerParameters));

// other code
}
finally
{
sqlDataReader.Close() // make sure reader is closed; generates out of
scope error
}


Would it not have been preferable to make objects declared try blocks
accessible in their corresponding finally block. Is there a benefit to this
retriction that I am missing?
Click to expand...

Yes - you wouldn't be able to use the variables anyway, as the code
path may not have even reached the variable declaration before the
exception was thrown.
 
Yes Gordon, you're right. I think I could have done a better job stating my
question.

What I am wondering is why Microsoft chose to implement the try/catch
constuct using code blocks knowing that this technique imposes the scope
restriction discussed in my initial post.

I believe the VB.NET try/catch construct does not impose this restriction
and, as a result, seems to be more intuitive and easier to work with - just
my opinion.

Thanks,
Chris
 
Thanks Jon, that makes sense.

Jon Skeet said:
Yes - you wouldn't be able to use the variables anyway, as the code
path may not have even reached the variable declaration before the
exception was thrown.
Click to expand...
 
SqlDataReader implements IDisposable, so you don't even need a try/finally
block for this particular case:

using (SqlDataReader sqlDataReader = new SqlDataReader(sqlConnection,
CommandType.StoredProcedure, "ConsumerGet", consumerParameters))
{
// other code
}

As for the syntax/semantics of try/catch, C# simply borrows from other
C-like languages; doing things (much) differently would likely create (a lot
of) confusion.

Dan
 
Chris
I believe the VB.NET try/catch construct does not impose this restriction
Click to expand...
Wrong! ;-) VB.NET imposes the same restriction.
and, as a result, seems to be more intuitive and easier to work with - just
my opinion.
Click to expand...
Yes it "seems" to ;-) However! At the same time it would cause a
Try/Catch/Finally statement to exhibit different blocking behavior then a
If/Then/Else statement in VB.NET.

Hope this helps
Jay

ChrisB said:
Yes Gordon, you're right. I think I could have done a better job stating my
question.

What I am wondering is why Microsoft chose to implement the try/catch
constuct using code blocks knowing that this technique imposes the scope
restriction discussed in my initial post.

I believe the VB.NET try/catch construct does not impose this restriction
and, as a result, seems to be more intuitive and easier to work with - just
my opinion.

Thanks,
Chris
Click to expand...
<<snip>>
 
Back
Top