Hi,
Would a global exception handler be considered lazy?
I mean I can use Try-Catch statements everywhere, but doesn't a global handler do the same?
Also, can I re-throw an exception from a catch block?
Thanks.
Printable View
Hi,
Would a global exception handler be considered lazy?
I mean I can use Try-Catch statements everywhere, but doesn't a global handler do the same?
Also, can I re-throw an exception from a catch block?
Thanks.
A global exception handler is always a good idea, if not a downright necessity. You should always include explicit exception handling, i.e. try...catch blocks, for any exceptions that you are aware of that could be thrown. That would include anywhere you're perfroming data access, disk I/O or anything else where there's an element beyond your control.
We all make mistakes though, and there may be points in your code that you have missed a possible exception or even introduced one. If you don't have a global exception handler then, at those points, your app will crash. That's just plain bad. A global exception handler won't fix the problem but it will allow you to exit gracefully while informing the user and logging the error.
Yes, you can re-throw an exception from a 'catch' block. In the C# IDE, if you type try and then hit Tab, this is what you get:Note that the exception that was caught is implicitly re-thrown by the 'throw' statement. You could do this too:csharp Code:
try { } catch (Exception) { throw; }but that's generally bad. By explicitly throwing the exception you remove its original call stack and the point it was re-thrown appears to be the source. You might also do this:csharp Code:
try { } catch (Exception ex) { throw ex; }This allows you to wrap an exception thrown by the system into a custom exception of your own creation. You'll see various exceptions that you catch yourself with inner exceptions and that's how they are created: catch, wrap, throw.csharp Code:
try { } catch (Exception ex) { throw new Exception("This is a custom exception", ex); }
That sounds reasonable.
But is it okay to let (at least custom) fatal exceptions stay unhandled?
Or would that be bad practice?
Also, I have a handler on Application.ThreadException and a handler on AppDomain.UnhandledException.
When is one fired and when is the other one?
Thanks.
Nice, didn't know that one :D
It' reasonable for a DLL to throw exceptions and assume that they will be handled by the referencing application but allowing exceptions to go unhandled in an application is terrible. Under what circumstances would allowing your app to crash with no logging and no explanation to the user be acceptable?I had no idea myself so I just opened the documentation for ThreadException. Thirty seconds work and I had the answer. If I can do that then you can. ALWAYS read the documentation first.
A global exception handler is something you would add to an application, not a library. Libraries don't crash because they don't run on their own. A library is a producer. An application is a consumer.
It's really very simple:
1. Anywhere that it makes sense to throw an exception, you should throw an exception.
2. Any code you write that can reasonably throw an exception should be wrapped in an exception handler UNLESS it is reasonable to assume that the exception will be handled at a higher level.
3. Always add a global exception handler to an application so that your application can exit gracefully with notification if an unexpected error occurs instead of falling in a heap and making you look like a bad programmer.