Reputation: 27
I'm in the needing of write a custom exception handler...
MY application is probably going to throw different kind of exceptions, and I would like they all get handled by a single handler (so that I don't need to use thousands of "try-catch" blocks).
I tried with the AppDomain's UnhandledException handler, but it seems that, when an exception is caught, the application will inevitably be closed.
So, is there any way I could accomplish my idea?
EDIT:
Thank you for your rapid replies, but I'd like to make you understand better my situation: I have, for example, a class which throws a custom exception (reversible). Now, this class, is called by multiple other class, so I would need to write a try-catch block on every single one of them (or at least this is what your replies make me think about)..
So, here comes the needing of have an handler capable of catch them all...
Upvotes: 1
Views: 2109
Reputation: 2807
You can use the AppDomain's UnhandledException Handler without closing the application. I do it too to log missed exceptions:
Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException);
Application.ThreadException += new System.Threading.ThreadExceptionEventHandler(Program_UnhandledException);
And
private static void Program_UnhandledException(object sender, System.Threading.ThreadExceptionEventArgs e)
{
//Handle the exception here...
}
Yet I do agree with the other answers, usually you shouldn't need a catch all exception handler. Handling exceptions where they occur should be the preferred action.
Edit: I don't know if it works the same way in console applications too.
Upvotes: 1
Reputation: 11051
Wrap your code in a try and catch block, which catches a Exception. All Exceptions are derived from Exception, so every exception that is thrown and not handled elsewhere is caught here. But remember if an exception is thrown, you deal with a possible invalid state of your application. You can't just always continue after an exception.
Another, rather direct approach is to register to the Application.ThreadException
(WinForms) but again, you should not use this if you plan to continue running the application. This is for cases where you want to display a message, maybe a way to send the error report and then close the application.
Upvotes: 0
Reputation: 70122
You should catch specific exceptions at the point in your code where you are best able to handle them. This should not result in thousands of try-catch blocks, rather, you should find localised areas of exception handling.
I tend to handle exceptions at service boundaries, for example, when interacting with databases or file-systems. At these service boundaries you can handle an exception and perform some logical recovery.
If you find yourself writing try-catch blocks where the catch does not add value, does not help your code recover, then you are not adding value by catching the exception!
Upvotes: 3
Reputation: 273179
You shouldn't need 'thousands' of try/catch blocks.
Only catch what you understand at the points where you can make a decision.
Catching an exception is very much part of your logic (unlike try/finally) and using 1 central handler usually won't do.
Consider this as an opportunity to study the proper use of exceptions.
Upvotes: 1
Reputation: 44316
try
{
// Code that needs exception handling
}
catch (Exception ex)
{
// Handle exception. You may use ex.GetType()
}
If this is not adequate, please explain why in your question.
Upvotes: -3