Are nested Try/Catch blocks a bad idea?
Solution 1
There are certain circumstances where they're a good idea, e.g. one try/catch for the whole method and another inside a loop as you want to handle the exception and continue processing the rest of a collection.
Really the only reason to do it is if you want to skip the bit that errored and carry on, instead of unwinding the stack and losing context. Opening multiple files in an editor is one example.
That said, exceptions should (as the name implies) be exceptional. A program should handle them but try to avoid them as part of normal execution flow. They're computationally expensive in most languages (Python being one notable exception).
One other technique which can be useful is catching specific exception types...
Try
'Some code to read from a file
Catch ex as IOException
'Handle file access issues (possibly silently depending on usage)
Catch ex as Exception
' Handle all other exceptions.
' If you've got a handler further up, just omit this Catch and let the
' exception propagate
Throw
End Try
We also use nested try/catches in our error handling routines...
Try
Dim Message = String.Format("...", )
Try
'Log to database
Catch ex As Exception
'Do nothing
End Try
Try
'Log to file
Catch ex As Exception
'Do nothing
End Try
Catch ex As Exception
'Give up and go home
End Try
Solution 2
I actually don't think there's anything inherently wrong about nested Try
/Catch
blocks, except that they can be difficult to navigate and are likely a sign that you could do some refactoring (the inner Try
/Catch
into its own method, for example).
But I do want to address this comment:
' Outer try code, that can fail with more generic conditions,
' that I know less about and might not be able to handle
If you don't know how to handle exceptions in a particular situation, trust me: don't catch them. Better to let your app crash (I mean, you know, log it; just don't swallow it) than to catch something you don't know how to recover from and then let your app continue merrily on its way in a corrupted state. Behavior will be unpredictable at best from that point on.
Goro
Updated on July 06, 2020Comments
-
Goro almost 4 years
Let's say we have a structure like so:
Try ' Outer try code, that can fail with more generic conditions, ' that I know less about and might not be able to handle Try ' Inner try code, that can fail with more specific conditions, ' that I probably know more about, and are likely to handle appropriately Catch innerEx as Exception ' Handle the inner exception End Try Catch outerEx as Exception ' Handle outer exception End Try
I have seen some opinions that nesting
Try
blocks like this is discouraged, but I could not find any specific reasons.Is this bad code? If so, why?
-
gooch over 13 yearsLogging in a background thread is a place i will use an inner try/catch. I don't want the method ending because it could not document what it was doing.
-
Basic over 13 years@Gooch true, I also do that, I'll add it to my answer.
-
Goro over 13 yearsThat is true. At the point of catching the outer exception I would not want to continue. I was more thinking of being able to shutdown/restart the application gracefully, and not shock the user with an "ugly crash"
-
Dan Tao over 13 years@Goro: In that case I would recommend an app-wide exception handling mechanism (e.g., if this is WinForms, handle the
Application.UnhandledException
event) rather than per-methodTry
/Catch
blocks.