C # exception handling experience (Principles and methods)

This article is an empirical article on Exception Handling. In fact, it has little to do with C. It is suitable for readers who are just familiar with the exception syntax but lack practical experience. Of course, experienced readers can also point out deficiencies, give comments, add explanations, improve articles together, and share more knowledge and experience. 1. When should I handle the exception? 1) The outermost layer of the Code, such as WinFrom, prevents users from seeing internal exceptions and poor user experience or program crash. 2) the location where an exception occurs that requires recovery or retry. For example, if the database connection fails by accident, you can have a reconnection mechanism to reconnect to the database in the Catch Block. 3) For a series of tasks that may fail, one of them fails and does not want to affect other tasks. For example, if you want to upload 100 images and do not want to fail due to an upload exception, you only need to record the failed images and remind the user to re-upload them. 2. Notes for exception handling 1) Catch and Finally code should be very short, and the success rate should be extremely high to avoid throwing another exception. Otherwise, the CLR terminates the process to avoid security vulnerabilities or unpredictable consequences. This is similar to the Windows blue screen, and a serious error occurs, rather than making the system unavailable. 2) Catch blocks should try to avoid directly capturing exceptions of the base class, but should Catch specific Exception classes. 3. Exception Handling Methods and Techniques 1) Can we build a unified framework to handle exceptions without manual handling? Some may ask if they can be lazy. Just handle exceptions in one place. If you only record abnormal system information and notify users, and the information usually lacks some context, you can build the same mechanism to record abnormal information. For example, the Application object of WinFrom provides the ThreadException time to capture the exception replication code static void Main () {// register and capture the exception event Application. threadException + = new System. threading. threadExceptionEventHandler (Application_ThreadException); Application. enableVisualStyles (); Application. setCompatibleTextRenderingDefault (false); Application. run (new Form1 ();} static void Application_ThreadException (object sender, System. threading. thread ExceptionEventArgs e) {Exception ex = e. exception; // perform some extremely simple operations to record Exception information} copy the Code, for example, Global of WebFrom. asax itself has defined void Application_Error (object sender, EventArgs e) to handle abnormal replication code void Application_Error (object sender, EventArgs e) {// code Exception ex = Server when an unprocessed error occurs. getLastError (); // clear the exception Server after handling the exception. clearError ();} copies the Code. However, in many cases, exception handling is not only required to record the error information, but sometimes requires failure and retrying or clearing resources. Therefore, it is not flexible to build a unified Exception Handling framework. Processing, on the other hand, can be handled separately.