Catch all exception good or bad?

I've seen in multiple projects a kind of catch all exception to catch all unexpected excepti开发者_如何学Con so the app won't crash, i see this usually with :

AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(myUnexpectedExhandler);
Application.ThreadException += new System.Threading.ThreadExceptionEventHandler(threadExHandler);

Is this a good or bad practice.

Catching exceptions at the top level of your project is fine and correct. There, you can do things such as log it, report the details back to your team, etc. Exceptions should definitely be published somewhere if at all possible -- that helps a lot in terms of developing a rock-solid product (see Jeff Atwood's blog post "Exception-Driven Development" for a commentary on this).

What is bad practice is catching exceptions inappropriately further down the call stack. The only time you should catch an exception is when you know exactly what to do with it. Certainly, you should never, ever, ever, ever silently swallow exceptions.

Overall, I would say it is entirely up to you, but for me it depends on what phase a given project is currently in. During initial development of any project, I prefer uncaught exceptions to display a nice descriptive error message with what line of code it bombed on so I can fix it.

Once a site matures, however, I use a custom ErrorHandler class I've built and have all errors logged into a database table, and also have an hourly (or daily) error list e-mailed to the developer in charge of the project. Special errors that require delicate handling will usually have a try/catch around the specific lines of code that could break.

Every project that I work on eventually gets a global exception handler like that.

I personally don't think it's good practice to solely rely on that in production. Any method or action that could cause an exception to be thrown should be handled at that stage (try..catch or passed to a custome handler class etc..). Not only does it make the application more robust, since you can handle specific exceptions in a way that is suitable to the situation, but it also makes it easier to find out why the exception is being thrown. There are many logging frameworks also available that make it easier to log exceptions and handle the errors.

I would use 'catch all' exceptions, but only as the very last line of error handling.

I would say it is a very debatable question among many programmers who have different experiences and tend to have different opinions.My answer might be little lengthy but I feel I cannot answer it short!!!

I believe in the following based on my experience:

1. Know the business requirement. If it is a critical application, yes you are very true we should not allow the application to continue and just allow it to crash by showing the user some appropriate message.
2. If it is not a very critical application, and you want the user to continue using the application by doing some other task, it makes sense to allow the application to recover gracefully.

To add to the above 2 points I would also like to say , you cannot recover any application if an unhandled application occurs in any thread which you have created. Only exceptions on the main GUI thread can be recovered.

The whole point of adding such code is to make sure debugging and error reporting becomes simpler and easy. For example, say you have a very big application and an unexpected exception occurs somewhere in your code. Now if you have such handlers like you mentioned, you can centralize the whole thing and log the stack trace, messages, etc. And once you have the entire log, its a matter of time to solve the issue and know its source.

I hope it helps!!

For my opinion it's a very good practice to catch and log exceptions in app-level.

BUT That does definitely NOT mean that you don't have to handle exceptions any more, you do have to handle to individual classes' exceptions that you excpect.

The application exceptions should be used only for the program not to crash and for logging purposes, not to be used as one big try-catch aound the application.

Again that was personal opinion.

I regularly use such exceptions handlers in production, and my practice is that I can use them to:

• inform user that something bad DID happen, but that I do care about it and will resolve it as soon as possible - it's better to do that instead of displaying standard boring windows crash dialog
• send an e-mail back to me with exception message, stack trace, and any other interesting info
• catch and recover from known exceptions that are unavoidable in code and try to move on in some less-catastrophic manner

HTH

I would think a global exception handler would be a good thing. If your program crashes then it allows you a single space to attempt spit out one more bit of data so you can hopefully find out why it crashed. Recovering from a global exception handler would not be suggested because its probably not the case that you know how to recover from an arbitrary exception at the top level.

If you're going to log the uncaught exception, always log a stacktrace with it! I hate getting bug reports that have a log like: "Unhandled exception" or "Unhandled exception: IndexOutOfRangeException"

Thanks, co-workers. That's great.