1. When should exception be handled?
1) The outermost layer of the code, such as WinFrom, avoids users from seeing internal abnormal information, and the user experience is poor, or causing program crashes.
2) Where an exception is encountered, you need to restore the state or try again. For example, if the connection to the database fails by chance, there can be a reconnect mechanism to reconnect the database in the Catch block.
3) For a series of tasks that may fail, one of which fails and does not want to affect other tasks. For example, if you want to upload 100 pictures, you do not want to fail because of an exception upload of one picture, and then terminate the entire upload task. You only need to record the failed pictures and remind the user to retransmit it.
2. Things to pay attention to when handling exceptions
1) The Catch and Finally codes should be very short and have a very high success rate, so you can avoid throwing another exception. Otherwise, the CLR will terminate the process to avoid security vulnerabilities or unpredictable consequences. This is similar to Windows Blue Screen, with a serious error that would rather make the system unavailable.
2) The Catch block should try to avoid directly catching exception base class Exception, but should catch specific exception classes.
3. Methods and techniques for exception handling
1) Can a unified framework be built to handle exceptions without manual processing?
Some people may ask, can you be lazy and just handle exceptions in one place. If you only record the exception system information and notify the user, and this information usually lacks some context, the same mechanism can be built to record the exception information.
For example:
WinFrom's Application object itself provides ThreadException time to catch exceptions for processing
static void Main()
{
//Register and catch exception events
+= new (Application_ThreadException);
();
(false);
(new Form1());
}
static void Application_ThreadException(object sender, e)
{
Exception ex = ;
//Do some extremely simple operations to record exception information
}
For example:
WebFrom itself has defined void Application_Error(object sender, EventArgs e) to handle exceptions
void Application_Error(object sender, EventArgs e)
{
// Code running when an unprocessed error occurs
Exception ex = ();
//Clear the exception after processing
();
}
However, many times, exception handling is not just about recording error information. Sometimes it requires failure to retry or clean up resources, etc. Therefore, it is not flexible enough to build an exception handling framework by relying solely on a unified basis. Therefore, it can be handled uniformly on one hand, and on the other hand, special places can be handled separately.