Some experience and tips on C exception handling

1. When should you handle exceptions?
1) The outermost layer of the code, such as WinFrom, can prevent users from seeing internal exception information. The user experience is not good, or the program crashes.
2) Where an exception needs to be restored or retried. For example, if the connection to the database fails accidentally, there can be a reconnection mechanism to reconnect to the database in the Catch block.
3) For the task that may fail in series 1, one of the tasks fails and it does not want to affect other tasks. For example, if you want to upload 100 pictures, you don't want to terminate the whole upload task due to the exception of one picture. You just need to record the failed pictures and remind the user to reupload.
2. Attention should be paid to exception handling
1) The Catch and Finally codes should be very short and have a high success rate to avoid throwing another exception yourself. Otherwise CLR will terminate the process, avoiding security holes or unpredictable consequences. This is similar to the Windows blue screen, where a serious error occurred and preferred to make the system unavailable.
2) Catch blocks try to avoid catching exceptions directly from the base class Exception, instead catching specific exception classes.
3. Methods and skills of exception handling
1) Can you build a framework to handle exceptions instead of handling them manually?
Some people might ask, can I be lazy and handle exceptions in one place? If only the exception system information is logged, notify the user, and the information is usually missing some context, it is possible to build the same mechanism to log the exception information.

Such as:
The Application object of WinFrom itself provides ThreadException time to catch exceptions for handling

static void Main()
    {
      // Register to catch exception events 
      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.ThreadExceptionEventArgs e)
    {
      Exception ex = e.Exception;
      // do 1 Some very simple operations to record exception information 
    }

Another example:
Global. asax of WebFrom itself defines void Application_Error(object sender, EventArgs e) to handle exceptions

void Application_Error(object sender, EventArgs e)
    {
      //  Code that runs when an unhandled error occurs 
      Exception ex = Server.GetLastError();
      // Clear the exception after handling it 
      Server.ClearError();
    }

But most of the time, exception handling, not only records the error information is ok, sometimes need to retry or failure to clean up resources, etc., as a result, only the series 1 to exception handling framework is flexible enough, so can be dealt with in 1 series 1, another special place 1 side can also processing.