Sum up 10 articles. NET Exception Handling Recommendations _ Practical Tips

. NET from beginning to end to remember the exception handling policy: Throw a specific exception, rather than just throw the exception type of exception, so that we can catch the corresponding type of exception. We need to be careful when writing code to take into account the worst of the application, display good information, and provide appropriate administrator contact information.

1, do not throw "new Exception ()"

Please don't do that. Exception is a very abstract exception class, and capturing such exceptions usually produces a lot of negative effects. In general, we should define our own exception classes, and we need to differentiate between the exceptions thrown by the system and the exceptions we throw ourselves.

2, do not store important exception information in the message property

Exceptions are encapsulated in the class. When you need to return exception information, store the information in separate properties (rather than in the message attribute), otherwise it is difficult for people to parse out the information they need from the messages attribute. For example, when you just need to correct spelling errors, if you write the error message and other hints in string form in the message attribute, how can someone simply get the wrong information they want? It's hard for you to imagine how much effort they have to make.

3, each thread to contain a try/catch block

General exception handling is placed in a relatively concentrated place in the program. Each thread needs to have a try/catch block, otherwise you will miss out on some anomalies to make it difficult to understand. When a program opens multiple threads to handle background tasks, you typically create a type to store the results of each thread execution. Do not forget to add a field for the type to store the exceptions that may occur for each thread, otherwise the main thread will not know the exception of other threads. In some "instant-forget" situations, you may need to copy the exception handling logic from the main thread into your child threads.

4, after catching the exception to record

It doesn't matter how your program logs--log4net, EIF, Event log, tracelisteners, or text files. The important thing is: when you encounter an exception, you should record it somewhere in the log. But just record it once, otherwise you end up with a very large log file that contains a lot of duplicate information.

5, do not only record the value of Exception.Message, also need to record exception.tostring ()

When we talk about logging, don't forget that we should record the value of exception.tostring () instead of 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 may only see a hint like "object references are not pointing to instances in the heap."

6, to capture the specific exception

If you want to catch an exception, try to catch the specific exception (not exception) as much as possible. Good code can only catch the exception that it knows what to do with

7, do not forget to use using

Simply calling the Dispose () method of an object is not enough. The Using keyword can prevent resource leaks even when an exception occurs

8, do not use the special return value to represent the exception that occurs in the method

1), throwing the exception directly is faster, because when using a special return value to represent an exception, every time we call the method, we need to check the return result, and it takes at least one more register. Reduce the speed at which your code runs.
2), special return value can, and is likely to be ignored
3), the special return value cannot contain the stack trace information, cannot return the exception the detailed information
4), many times, there is no special value to represent the exception in the method, for example, the divisor is zero

9, do not put "throw exception" as a function of the result of a

This is a very bad design. The code contains too many Try/catch blocks that make the code difficult to understand, and the proper design can completely satisfy a method that returns a variety of execution results, and if you do need to represent the execution result of the method by throwing an exception, it only means that you have done too many things in this way and have to split

10, you can use the "throw an exception" to highlight the error can not be ignored

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

Ps:. Four elements of net exception handling

1. A class that represents the details of an exception.
2. A member that resembles a caller to throw an exception class instance.
3. A module of the caller that invokes the exception member.
4. A section of the caller handles or captures the code block that will occur.