a try inside another
-
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...
-
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.
If you're in a helper layer such as a DAL then you don't want to add any code that will interact with the user, however you may want to do clean up before the exception is thrown up the chain to a level where the exception can be dealt with by the user. Equally what's the difference between the original example and the following?
Private Sub ExceptionMethod() Try DoExceptionCode() Finally DoCleanup() End Try End Sub Private Sub ExceptionHandlerCode() Try ExceptionMethod() Catch ex As Exception ExceptionHandlerHere() End Try End Sub -
If you're in a helper layer such as a DAL then you don't want to add any code that will interact with the user, however you may want to do clean up before the exception is thrown up the chain to a level where the exception can be dealt with by the user. Equally what's the difference between the original example and the following?
Private Sub ExceptionMethod() Try DoExceptionCode() Finally DoCleanup() End Try End Sub Private Sub ExceptionHandlerCode() Try ExceptionMethod() Catch ex As Exception ExceptionHandlerHere() End Try End SubArrgggh - my eyes. The horror. Case insensitive code in our lovely curly bracketed case sensitive world.
Forgive your enemies - it messes with their heads
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
-
Arrgggh - my eyes. The horror. Case insensitive code in our lovely curly bracketed case sensitive world.
Forgive your enemies - it messes with their heads
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
Sorry, I'll use Smalltalk next time. More seriously I had a vb editor open so it was just quicker to type it in there with the auto complete than to start up a new c# editor for the example (formatting purposes)
-
Sorry, I'll use Smalltalk next time. More seriously I had a vb editor open so it was just quicker to type it in there with the auto complete than to start up a new c# editor for the example (formatting purposes)
DragonLord66 wrote:
I had a vb editor open
In the name of all that's holy man, why?
Forgive your enemies - it messes with their heads
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
-
DragonLord66 wrote:
I had a vb editor open
In the name of all that's holy man, why?
Forgive your enemies - it messes with their heads
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
We have a very large code base of VB code that was written simply because it's easier to get a working prototype in vb (pre 2010 and c# runtime code editing), and the prototypes turned into production 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.
My memory may not be correct, but I seem to recall a time in C++ when try-finally was a macro and try-catch a language intrinsic, so you couldn't mix them together. If you wanted to do both, you pretty much had to code it up that way. Maybe I recall wrong though? Unless there's more code inside the try-catch that isn't inside the try-finally, it doesn't make much sense to code it that way.
patbob
-
Arrgggh - my eyes. The horror. Case insensitive code in our lovely curly bracketed case sensitive world.
Forgive your enemies - it messes with their heads
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
Oh come on, its just another way of saying (explaining) the same thing.
-
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.
That's a do-while. :laugh: