As a rule, in every application I write, I always implement both the Application.ThreadException and AppDomain.UnhandledException events, to catch exceptions which were not caught by a try..catch block.
There are three reasons behind this:
Present a custom failure message to the user (something like Twitter’s fail whale message) instead of the default ugly (and unclear) error dialog, i.e. “XXX.exe has encountered a problem and needs to close. We are sorry for the inconvenience.“
Log the exception so it may be resolved in future releases.
Although it’s not considered as a good practice, some exception may be ignored so the application may keep on running, instead of crashing
<runtime>
<legacyunhandledexceptionpolicy enabled="”1″">
<runtime>
<configuration>
</configuration></runtime></legacyunhandledexceptionpolicy></runtime></configuration>
Read more: Dotmad (on .Net)
There are three reasons behind this:
Present a custom failure message to the user (something like Twitter’s fail whale message) instead of the default ugly (and unclear) error dialog, i.e. “XXX.exe has encountered a problem and needs to close. We are sorry for the inconvenience.“
Log the exception so it may be resolved in future releases.
Although it’s not considered as a good practice, some exception may be ignored so the application may keep on running, instead of crashing
-
<configuration>