a try inside another
-
Rick van Woudenberg wrote:
But what's the use of a try block without a catch block.
To ensure that the exception gets thrown up the chain, AND some critical piece of code gets executed. Consider this example:
private void DoSomething()
{
SqlConnection connection = null;
try
{
connection = new SqlConnection();
// Do something that might cause an exception...
}
finally
{
if (connection.ConnectionState == ConnectionState.Open)
connection.Close();
}
}BTW,
try/finallyis exactly how the using statement is implemented for auto-disposable behaviour.Forgive your enemies - it messes with their heads
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
Pete, Good point. I guess you're sample is way better than I used to do it. ( see code below ). Other than the obvious thread freezing and just the fact that handling exceptions are 'expensive'.
private void DoSomething()
{
SqlConnection connection = null;
try
{
connection = new SqlConnection();
// Do something that might cause an exception...
connection.Open();
}
catch
{
MessageBox.Show("Connecting to the database failed..");
}if (connection.ConnectionState == ConnectionState.Open)
connection.Close();
} -
this will hide the inner exception of the inner try?
Help people,so poeple can help you.
the finally block is always executed, and any exception that gets thrown will be caught by the first surrounding and matching catch block. So the finally block will execute first (unless the catch belongs to the same try as the finally). :)
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
-
Pete, Good point. I guess you're sample is way better than I used to do it. ( see code below ). Other than the obvious thread freezing and just the fact that handling exceptions are 'expensive'.
private void DoSomething()
{
SqlConnection connection = null;
try
{
connection = new SqlConnection();
// Do something that might cause an exception...
connection.Open();
}
catch
{
MessageBox.Show("Connecting to the database failed..");
}if (connection.ConnectionState == ConnectionState.Open)
connection.Close();
} -
guys; I was exminning some code and i found this:
try { try { ... } finally { ... } } catch { throw; }I am wondering if this is legal. I mean catch anything and trow anything; or maybe it's usefull for something. because the developer who write this code is someone i believe he is an expert. Thank you;
Help people,so poeple can help you.
The outer try/catch in this example is pointless, remove it. If the catch in the outer try/catch actually does something (like log the Exception), then the inner try/finally should be removed and the finally moved out to make the try/catch into a try/catch/finally. Nested try/catches (while sometimes necessary) are a code smell and should be investigated thoroughly. (Or Thoreau[^]ly -- simplify simplify.)
-
The outer try/catch in this example is pointless, remove it. If the catch in the outer try/catch actually does something (like log the Exception), then the inner try/finally should be removed and the finally moved out to make the try/catch into a try/catch/finally. Nested try/catches (while sometimes necessary) are a code smell and should be investigated thoroughly. (Or Thoreau[^]ly -- simplify simplify.)
PIEBALDconsult wrote:
If the catch in the outer try/catch actually does something (like log the Exception), then the inner try/finally should be removed and the finally moved out to make the try/catch into a try/catch/finally.
If the catch in the outer try/catch actually does something, then your suggestion would change what happens to exceptions thrown by the finally block itself. :)
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
-
Rick van Woudenberg wrote:
But what's the use of a try block without a catch block.
To ensure that the exception gets thrown up the chain, AND some critical piece of code gets executed. Consider this example:
private void DoSomething()
{
SqlConnection connection = null;
try
{
connection = new SqlConnection();
// Do something that might cause an exception...
}
finally
{
if (connection.ConnectionState == ConnectionState.Open)
connection.Close();
}
}BTW,
try/finallyis exactly how the using statement is implemented for auto-disposable behaviour.Forgive your enemies - it messes with their heads
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
-
Suppose the line
connection = new SqlConnection();
fails and connection stays null. Won't you receive a very ugly "unhandled exception" message? (haven't tried it).
V.
You will, but the exception will bubble up (actually, in this case you won't get an exception. The zero parameter constructor doesn't do anything that can cause an exception). I deliberately didn't put exception handling in here to avoid clouding the issue.
Forgive your enemies - it messes with their heads
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
-
That code example made me shudder. Separation of concerns; Is the concern database access or User notification, because it sure as hell shouldnt be both.
Well, as far as I'm concerned both would be nice. Sure, the connection to the database has priority over user notification, however when something stuffs up, I generally let the user know. In that particular case I would do something like :
private void DoSomething()
{
SqlConnection connection = null;
try
{
connection = new SqlConnection();
// Do something that might cause an exception...
connection.Open();
}
catch(SqlException ex)
{
MessageBox.Show(ex.ToString(); // or something else to notify the customer
}
finally
{
if (connection.ConnectionState == ConnectionState.Open)
connection.Close();
}
}Then you actually have both of two worlds. However, that puts us right back to the essence of this discussion. Having a catch clause in a method is not something to be ashamed of, though I get the feeling that many developers think that way.
-
Well, as far as I'm concerned both would be nice. Sure, the connection to the database has priority over user notification, however when something stuffs up, I generally let the user know. In that particular case I would do something like :
private void DoSomething()
{
SqlConnection connection = null;
try
{
connection = new SqlConnection();
// Do something that might cause an exception...
connection.Open();
}
catch(SqlException ex)
{
MessageBox.Show(ex.ToString(); // or something else to notify the customer
}
finally
{
if (connection.ConnectionState == ConnectionState.Open)
connection.Close();
}
}Then you actually have both of two worlds. However, that puts us right back to the essence of this discussion. Having a catch clause in a method is not something to be ashamed of, though I get the feeling that many developers think that way.
-
ahhh, no no no. If your UI code is mixed with your database access code; you're doing it wrong If you show Exception messages unsanitized to your users; you're doing it wrong
Totally agreed on the first point. But regarding the second, he did mention that he might put something else there. I tend to have something which shows them the exception trace in the critical exception handler, because if there is a serious bug, you (the developer) want that information to fix it. In the case of a database connection failure, though, definitely not, because most of those reasons are not because your software is broken.
-
Totally agreed on the first point. But regarding the second, he did mention that he might put something else there. I tend to have something which shows them the exception trace in the critical exception handler, because if there is a serious bug, you (the developer) want that information to fix it. In the case of a database connection failure, though, definitely not, because most of those reasons are not because your software is broken.
BobJanova wrote:
you (the developer) want that information to fix it
And therein is the point. I want it, but I dont EVER want a user to see it. This is what the Windows Event Log (or, perhaps another type of log) is for. You never have a reason to show a user an unsanitized exception message (caveat: they're programmers and can actually act on the information). There is the potential to give away sensitive information if you do so.
-
BobJanova wrote:
you (the developer) want that information to fix it
And therein is the point. I want it, but I dont EVER want a user to see it. This is what the Windows Event Log (or, perhaps another type of log) is for. You never have a reason to show a user an unsanitized exception message (caveat: they're programmers and can actually act on the information). There is the potential to give away sensitive information if you do so.
J4amieC wrote:
This is what the Windows Event Log (or, perhaps another type of log) is for.
Or to put it another way - that's what log4net is for. :-D
Forgive your enemies - it messes with their heads
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
-
PIEBALDconsult wrote:
If the catch in the outer try/catch actually does something (like log the Exception), then the inner try/finally should be removed and the finally moved out to make the try/catch into a try/catch/finally.
If the catch in the outer try/catch actually does something, then your suggestion would change what happens to exceptions thrown by the finally block itself. :)
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
Luc Pattyn wrote:
exceptions thrown by the finally block itself.
Of which there are none. or put a try/catch in the finally. :-D
-
Luc Pattyn wrote:
exceptions thrown by the finally block itself.
Of which there are none. or put a try/catch in the finally. :-D
PIEBALDconsult wrote:
Of which there are none
Of course there are, that is exactly what the three dots are standing for. You can't escape nested try constructs if it has to be fool proof... :)
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
-
PIEBALDconsult wrote:
Of which there are none
Of course there are, that is exactly what the three dots are standing for. You can't escape nested try constructs if it has to be fool proof... :)
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
Luc Pattyn wrote:
You can't escape nested try constructs
Sure I can, I'll write a method. And I did say that some times they're necessary. However, taking the least scope route, if you want to protect against Exceptions in a finally (and you shouldn't need too), then put the try/catch there.
-
The outer try/catch in this example is pointless, remove it. If the catch in the outer try/catch actually does something (like log the Exception), then the inner try/finally should be removed and the finally moved out to make the try/catch into a try/catch/finally. Nested try/catches (while sometimes necessary) are a code smell and should be investigated thoroughly. (Or Thoreau[^]ly -- simplify simplify.)
Pointless with regards to how the code executes, but not pointless if you are debugging. The outer catch block gives you a place to put a breakpoint so you can see when exceptions occur. I expect that is the reason for it. But the outer try-catch block can be safely removed for production code.
-
ahhh, no no no. If your UI code is mixed with your database access code; you're doing it wrong If you show Exception messages unsanitized to your users; you're doing it wrong
I totally agree with you, and I would never show an exception to a user. Hence the
// or show something else..
, but I still think that you should at least say something when anything important messes up, like .. euhh .. a database connection that fails ? I don't think it's wise to redirect general user messages that could be caused by an exception to the windows logs. Not very user friendly.
-
ahhh, no no no. If your UI code is mixed with your database access code; you're doing it wrong If you show Exception messages unsanitized to your users; you're doing it wrong
J4amieC wrote:
If your UI code is mixed with your database access code; you're doing it wrong
If you show Exception messages unsanitized to your users; you're doing it wrongAhhh, no. It depends upon the scope of the problem you're trying to solve. If this is a 1,000 line utility app that you're the only user for, this might be perfectly appropriate. If it's a 200,000 line client for a LOB app, then you might have issues.
Software Zen:
delete this; -
Pointless with regards to how the code executes, but not pointless if you are debugging. The outer catch block gives you a place to put a breakpoint so you can see when exceptions occur. I expect that is the reason for it. But the outer try-catch block can be safely removed for production code.
Then put a catch on the try/finally.
-
Then put a catch on the try/finally.
Except if the exception occurs during execution of the finally-block...