157 recommendations for writing high-quality code to improve C # programs--recommendation 63: Avoid "eating" exceptions

Recommendation 63: Avoid "eating" exceptions

Nesting exceptions is a risky behavior, and accidentally hides the exception stack information, which is the true source of the bug. This is not the most serious, the most serious is "eat" the exception, that is, capture, and then do not throw to the upper layer.

Avoiding the "Eat" exception does not mean that you should not "eat" the exception, but there is an important principle here: The exception can be foreseen, and usually it is not considered a bug.

Imagine that you are decrypting tens of thousands of files from different clients, and that there is a case that the file is corrupted, and your goal is to insert the decrypted data into the database. This time, you have to ignore the decryption failure of the file, the whole process to go on. Of course, logging is necessary, because later you may be able to decrypt the failed files to do a unified processing.

In another case, it may not even be necessary to log logs. In distributed systems where thousands of controlled terminals are controlled, the control terminal needs to publish the heartbeat data to determine the online situation on the controlled side. The usual practice is to maintain a model quantity, if in an acceptable block time (such as 500ms) heartbeat data transmission failure, then the control thread will not receive a signal, that is, can judge the short-term status of the controlled side. In this case, it is usually meaningless to record each socketexception.

If you do not know how to handle an exception, then do not "eat" the exception, if you accidentally "eat" an exception that should be passed on, then you may be born a bug, and solve it will be a lot of trouble.

Turn from: 157 recommendations for writing high-quality code to improve C # programs Minjia

157 recommendations for writing high-quality code to improve C # programs--recommendation 63: Avoid "eating" exceptions