a try inside another
-
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.
-
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.
Guy ( or girl .. dunno ) A try is always followed by a catch section, hence the name try.catch block. The sample you provided is legal, however I would add an additional catch block in case anything goes wrong in the second try section.
try { try { ... } catch { //Do Something to alert the user } finally { ... } } catch { throw; } -
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.
that is perfectly legal. The outer try-catch will catch whatever gets thrown outside the inner try block, e.g. an exception occurring in the inner finally block. :)
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.
-
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.
A catch block containing nothing but a rethrow is by definition pointless. That is,
try {
doStuff();
} catch {
throw;
}... is equivalent to simply calling doStuff(). So, if you haven't simplified out some code from the catch block, the outer try is pointless. However, in the general case, this type of construct can be useful, because of the order of operations. In your example, if an exception is thrown, code is executed in the order inner-try, finally, catch, which means that the exception handler is called after the finally has been called and cleaned up. In a standard try { ... } catch { ... } finally { ... }, the order is try, catch, finally, so exception handlers are called before cleanup. If your exception handler is logging, aborting execution or calling something which assumes that the data is in a good state, the former can be better. Edit: also, Luc makes a good point, if the finally code throws an exception, this structure will catch it, though finally code should not throw exceptions unless it is truly unavoidable.
-
Guy ( or girl .. dunno ) A try is always followed by a catch section, hence the name try.catch block. The sample you provided is legal, however I would add an additional catch block in case anything goes wrong in the second try section.
try { try { ... } catch { //Do Something to alert the user } finally { ... } } catch { throw; }Rick van Woudenberg wrote:
A try is always followed by a catch section, hence the name try.catch block.
Incorrect. A try-finally construct is perfectly legal. It is only when a try block is followed by a catch block that they are called a try-catch construct. :)
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:
A try is always followed by a catch section, hence the name try.catch block.
Incorrect. A try-finally construct is perfectly legal. It is only when a try block is followed by a catch block that they are called a try-catch construct. :)
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.
.. euhmm .. debatable I guess. Technically speaking you're right, I agree. But what's the use of a try block without a catch block. The try block contains the guarded code that may cause the exception. The block is executed until an exception is thrown or it is completed successfully. The catch clause can be used without arguments, in which case it catches any type of exception, and referred to as the general catch clause. It can also take an object argument derived from System.Exception, in which case it handles a specific exception. So, keeping all that in mind, I'm hard to convince why you'd want two or more try clauses with just one catch clause, as each try block is examined in order of importance and thus handled by the same catch clause. .. or have I completely lost my mind again.
-
that is perfectly legal. The outer try-catch will catch whatever gets thrown outside the inner try block, e.g. an exception occurring in the inner finally block. :)
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.
this will hide the inner exception of the inner try?
Help people,so poeple can help you.
-
this will hide the inner exception of the inner try?
Help people,so poeple can help you.
Well, if you don't use an inner catch, every exception in both the inner and outer try block, will be caught by the outer catch block.
-
.. euhmm .. debatable I guess. Technically speaking you're right, I agree. But what's the use of a try block without a catch block. The try block contains the guarded code that may cause the exception. The block is executed until an exception is thrown or it is completed successfully. The catch clause can be used without arguments, in which case it catches any type of exception, and referred to as the general catch clause. It can also take an object argument derived from System.Exception, in which case it handles a specific exception. So, keeping all that in mind, I'm hard to convince why you'd want two or more try clauses with just one catch clause, as each try block is examined in order of importance and thus handled by the same catch clause. .. or have I completely lost my mind again.
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
-
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.