Do not use printStackTrace() for online code
After writing the code, please be sure to check it. Do not have printStackTrace() in the code. Because printStackTrace() will only output the wrong stack information on the console, it is only suitable for code debugging. If you really need to log exceptions, please use logging.
Never swallow exceptions in catch blocks
Never fail to handle the exception, but return null, so that the exception will be swallowed and no failure information can be obtained, which will bring great difficulties to future troubleshooting.
Declare specific checked exceptions where needed
The above code must be avoided as much as possible, because its caller has no idea what the cause of the error is.
In the method declaration, some specific checked exceptions can be thrown by the method. If there are multiple, throw multiple separately, so that the user of this method will deal with each exception separately, so as to avoid failure.
This is a basic concept. When you can handle it, you should catch this exception, otherwise you should never catch it.
If you can't handle it in the catch block, then don't catch it first and then throw it directly, it doesn't make any sense.
Try to capture specific subclasses instead of directly capturing the Exception class
The biggest problem with the above code is that if the developer of someMethod() adds a specific exception in it, and it is expected that the caller can handle it specially.
However, if the caller directly catches the Exception class, it will never know the specific change details of someMethod. This may cause the program to crash at a certain point in the running process.
Never catch the Throwable class
This is a serious problem, because Error in Java can also be a subclass of Throwable. But Error is beyond the control of the Java virtual machine itself. The Java virtual machine may not even request the user's catch clause when there is any error.
Always overwrite the original exception in the custom exception so that the stack trace will not be lost
catch (NoSuchMethodException e)
{
throw new MyServiceException("Some information: " + e.getMessage()); //错误做法 }
The above command may lose the stack trace of the main exception. The correct way is:
You can log exceptions or throw exceptions, but don't do both at the same time
As shown in the code above, throwing and logging may produce multiple log messages in the log file.
This will lead to the same problem, but there are many different error messages in the log, causing developers to fall into confusion.
Never throw an exception in finally
In the above example, if someMethod() throws an exception, and in the finally block, cleanUp() also throws an exception, then the initial exceptionOne (correct error exception) will be lost forever.
If you do not intend to handle exceptions, use finally block instead of catch block
This is also a good practice. If you access other methods in your method, and the method throws an exception and you don't want to handle it, but still need to do some cleanup work, then clean up in the finally block. Don't use catch blocks.