9 best practices for handling Exception in Java!
Handling exceptions in Java is not a simple matter.
Not only beginners are difficult to understand the exceptions, even some experienced developers need to spend a lot of time thinking about how to deal with exceptions, including which exceptions need to be handled, how to deal with it, and so on. This is why most development teams will formulate some rules to regulate the handling of exceptions. And these norms between teams are often completely different.
This article gives several exception handling best practices used by many teams.
- 9 best practices for handling Exception in Java!
- Clean up resources in the Finally block or use try-with-resource statements
- Specify specific exception
- Document the exception
- Include description information when throwing an exception.
- Catch the most specific exception first
- Don’t catch Throwable
- Don’t ignore the exception
- Don’t log and throw exceptions
- Don’t discard the original exception when packaging the exception
- Summary
9 best practices for handling Exception in Java!
Clean up resources in the Finally block or use try-with-resource statements
When using resources like InputStream that need to be closed after use, a common mistake is to close the resource at the end of the try block.
The above code runs without any exceptions and there is no problem. But when the statement in the try block throws an exception or the code implemented by oneself throws an exception, then the final closing statement will not be executed, and the resources cannot be released.
A reasonable approach is to put all cleanup code in a finally block or use a try-with-resource statement.
Specify specific exception
Use the most specific exception to declare the method as much as possible, so as to make the code easier to understand.
As above, NumberFormatException can be seen literally as a number formatting error.
Document the exception
When an exception is declared on a method, it also needs to be documented. The same as the previous point, it is to provide the caller with as much information as possible, so as to better avoid/handle exceptions. 10 best practices for exception handling, this article is also recommended to read.
Add the throws statement in the Javadoc and describe the scenario where the exception is thrown.
Include description information when throwing an exception.
When throwing an exception, you need to describe the problem and related information as accurately as possible, so that whether it is printed in a log or a monitoring tool, it can be more easily read by people, so that you can better locate the specific error message and the severity of the error Degree etc.
But this is not to say that there is a long discussion about the error message, because the original class name of Exception can reflect the cause of the error, so it only needs to be described in one or two sentences.
NumberFormatException tells that the exception is a formatting error, and the additional information of the exception only needs to provide the error string. When the name of the exception is not obvious enough, you need to provide as specific error information as possible.
Catch the most specific exception first
Many IDEs can now intelligently prompt this best practice. When you try to catch the most general exception first, you will be prompted for unreachable code. When there are multiple catch blocks, only the first matching catch block can be executed according to the capture order. Therefore, if IllegalArgumentException is caught first, then the capture of NumberFormatException cannot be run.
Don’t catch Throwable
Throwable is the parent class of all exceptions and errors. You can catch in the catch statement, but never do it. If the throwable is caught, not only will it catch all exceptions, but also errors. The error is a jvm error that cannot be recovered. Therefore, unless you are absolutely certain that you can handle or are required to handle errors, do not capture throwable.
Don’t ignore the exception
In many cases, developers are confident that they will not throw exceptions, so they write a catch block, but do not do any processing or log.
But the reality is that there are often unexpected exceptions or it is impossible to determine whether the code here will be changed in the future (the code that prevents exceptions from being thrown is deleted), and at this time, because the exception is caught, it is impossible to get enough error information to locate problem. A reasonable approach is to at least record abnormal information.
Don’t log and throw exceptions
It can be found that many codes and even class libraries have logic to catch exceptions, record logs and throw them again. as follows:
This processing logic seems reasonable. But this often outputs multiple logs for the same exception. as follows:
As shown above, there is no more useful information attached to the following log. If you want to provide more useful information, you can wrap the exception as a custom exception.
Therefore, only catch the exception when you want to handle it, otherwise you only need to declare in the method signature for the caller to handle it.
Don’t discard the original exception when packaging the exception
It is a common practice to catch standard exceptions and package them as custom exceptions. In this way, more specific exception information can be added and specific exception handling can be done.
It should be noted that when packaging exceptions, the original exception must be set to cause (Exception has a construction method that can be passed to cause). Otherwise, the loss of the original exception information will make error analysis difficult.
Summary
In summary, when throwing or catching an exception, there are many different things to consider. Many of these points are to improve the readability of the code or the usability of the API. Exceptions are not only an error control mechanism, but also a communication medium, so discussing these best practices with your collaborators and developing some specifications will allow everyone to understand the relevant common concepts and be able to use them in the same way.
