Summarize ten. NET exception handling suggestions

In. NET, we should remember the exception handling strategy from beginning to end: throw a specific exception instead of only throwing an exception of Exception type, which can facilitate us to catch the exception of the corresponding type. When we write code, we should pay attention to the worst-case situation of the application; Display good information and provide appropriate administrator contact information.

1. Don't throw "new Exception ()"

Please don't do this. Exception is a very abstract exception class, and catching such exceptions usually has many negative effects. Normally, we should define our own exception classes, and we need to distinguish between exceptions thrown by the system and those thrown by ourselves.

2. Do not store important exception information in the Message property

Exceptions are encapsulated in classes. When you need to return exception information, store the information in a separate attribute (not in the Message attribute), otherwise it will be difficult for people to parse the information they need from the Message attribute. For example, when you only need to correct 1 spelling error, if you write the error message and other prompts 1 in the Message attribute in the form of String, how can others simply get the error message they want? You can hardly imagine how much effort they have to make.

3. Each thread should contain 1 try/catch block

1 exception handling is placed in a relatively concentrated place in the program. Each thread needs to have an try/catch block, otherwise you will miss some exceptions and cause problems that are difficult to understand. When a program opens multiple threads to handle background tasks, you usually create a type to store the results of each thread's execution. Don't forget to add a field to the type to store the exceptions that may occur to each thread, otherwise the main thread will not know the exceptions of other threads. In some "send and forget" situations, you may need to copy the exception handling logic from the main thread to your child thread.

4. Record the exception after catching it

It doesn't matter how your program logs-log4net, EIF, Event, Log, TraceListeners or text files. It is important that when you encounter an exception, you should log it somewhere. But please log only once, otherwise, you end up with a very large log file containing a lot of duplicate information.

5. Don't just record the value of Exception. Message, but also record Exception. ToString ()

When we talk about logging, don't forget that we should record the value of Exception. ToString (), not Exception. Message. Because Exception. ToString () contains "stack trace" information, internal exception information, and Message. Usually this information is very important, and if you only record Exception. Message, you can only see a hint like "the object reference does not point to an instance in the heap".

6. To catch specific exceptions

If you want to catch exceptions, catch specific exceptions as much as possible (instead of Exception). Good code only catches exceptions that it knows how to handle

7. Don't forget to use using

It is not enough to just call the Dispose () method of the object. The using keyword prevents resource leakage even when an exception occurs

8. Do not use special return values to represent exceptions that occur in methods

1). It is faster to throw an exception directly, because when using a special return value to represent an exception, we need to check the return result every time we call the method, and this takes up at least one more register. Slow down the code running speed.
2) Special return values can and are likely to be ignored
3) The special return value cannot contain stack trace information and cannot return the details of the exception
4) Most of the time, there is not a special value to represent an exception that occurs in a method, for example, when the divisor is zero

9. Don't use "Throw Exception" as one of the results of function execution

This is a very bad design. The code contains too many try/catch blocks will make the code difficult to understand, the proper design can completely satisfy a method to return a variety of different execution results, if you really need to throw exceptions to express the execution results of the method, it only shows that you have done too many things in this method, must be split

10. You can use the method of "throwing exception" to highlight errors that cannot be ignored

For example, I developed an API (Login) for one of my products to log in. If the user fails to log in, or if the user does not call the Login method, they will fail to call other methods. I did this when designing the Login method: If the user fails to log in, it throws an exception instead of simply returning false. Because of this, the caller (user) will not ignore the fact that he is not logged in yet.

ps:. Net 4 Elements for Exception Handling

1.1 Classes that represent exception details.
2.1 members of the class instance that throws an exception like the caller.
3. The caller's 1 segment calls the module of the exception member.
4. The caller's 1 segment handles or catches the code block where the exception will occur.