exception handling strategy
System exceptions can be divided into two categories: business exceptions and technical exceptions . As the name implies, business class exceptions can be understood as exceptions that occur during business logic processing. For example, when creating a customer order, it is found that there is no price set for this customer; when withdrawing money, the withdrawal amount is greater than the account balance, etc.
Technical exceptions are better understood. This layer is related to technical personnel and should be transparent to system users. For example, the database cannot be connected correctly; when accessing an array or list, the index is out of range; when performing calculations, the division by zero, etc.
For different types of exceptions, we will adopt different processing strategies, please refer to the following table.
| predictable anomalies | Unpredictable exception | |
| business class exception |
|
|
| technical exception |
|
|
exception refactoring
Before talking about exception refactoring, let's look at the following code
public void writeFile(String fileName, String data) {
FileWriter writer = null;
writer = new FileWriter(fileName);
writer.write(data);
}
This way of writing cannot be compiled, because the IOException exception is declared when the write method of FileWriter is defined, and the compiler requires us to handle this exception at the calling place.
public void writeFile(String fileName, String data) {
FileWriter writer = null;
try {
writer = new FileWriter(fileName);
writer.write(data);
} catch (IOException e) {
//everything
}
}
Or explicitly declare this exception in our custom method header.
public void writeFile(String fileName, String data) throws IOException {
FileWriter writer = null;
writer = new FileWriter(fileName);
writer.write(data);
}
Or handle this exception where it is called.
For the first method, we did not deal with the exception, but only used the try catch statement to catch the exception, and marked the todo for later processing, but it was easily forgotten after a long time. Some friends may say that using continue in the catch statement throws the exception
public void writeFile(String fileName, String data) {
FileWriter writer = null;
try {
writer = new FileWriter(fileName);
writer.write(data);
} catch (IOException e) {
throw e;
}
}
This approach is not advisable, because it will bring the problem back to the original point, and we still have to handle the exception thrown by us in the function that calls writeFile!
The second method, which is similar to using throw e, also does not handle the exception and passes it out again.
At this time, you need to consider refactoring exception handling. We start by defining an unhandled exception class.
/**
*
* @author Chris Mao(Zibing)
*
*/
public class UnhandledException extends Exception {
private Exception exception;
private String message;
/**
*
*/
private static final long serialVersionUID = 3490319235806360289L;
public UnhandledException(Exception e, String message) {
this.exception = e;
this.message = message;
}
public Exception getException() {
return exception;
}
public String getMessage() {
return message;
}
}
Then change the code mentioned at the beginning of the article to the following.
public void writeFile(String fileName, String data) throws UnhandledException {
FileWriter writer = null;
try {
writer = new FileWriter(fileName);
writer.write(data);
} catch (IOException e) {
throw new UnhandledException(e, "This exception will be discussed later, let the business function run first");
}
}
This can not only meet the requirements of rapid development, but also ensure that the handling of this exception will not be forgotten in the future.