Avoid using CheckedException in Java

Avoid using CheckedException-general Linux technology-Linux programming and kernel information in Java. The following is a detailed description. This article points out some shortcomings of checked Exception in Java, and proposes to avoid using checked Exception in programming. For code that needs to handle checked Exception, you can use the ExceptionAdapter class to wrap the checked Exception. The concept of this article and the ExceptionAdapter class are derived from Bruce Eckel's Does Java need Checked Exception.


Java Exception is divided into two types: RuntimeException and its subclass, and checked Exception. Java requires the function to write the checked Exception that has not been caught. However, this requirement often brings unnecessary burden to programmers.



To avoid writing throws in function declaration, the following code is often seen in Java projects to 'swapp' Exception:
Try {

//...

} Catch (Exception ex ){

Ex. printStackTrace ();

}




This is obviously not a good way to handle exceptions. In fact, catch and handle an Exception means that the program can be recovered from the Exception. In this sense, the Code already in use can only work in some very simple situations without causing problems.



For many exceptions, the only thing that can be done is to display some prompts on the interface. In this case, the Exception thrown by the program is more reasonable. However, this will cause the declaration of some functions to expand sharply. A function may need to declare 7 or 8 checked exceptions that will be thrown, and each function that calls it also needs the same declaration.



Worse than this, it may damage the open-close principle of class design. To put it simply, the open-close principle means that when a module is extended, the existing client is not affected. The open-close principle is implemented through inheritance. When inheriting a class, we extend this class without affecting the original client (because this class has not been changed ).



Consider the following situation: there is a parent class Base:

Public class Base {



Public void foo () throws writable tiona {

//...

}

}




Now we need to inherit the Base class and reload the foo method. In the new implementation, foo may throw ExceptionB:
Public class Extend extends Base {



Public void foo () throws ExceptionB {

//...

}

}




However, writing the Exception in Java is invalid because Java regards the Exception that may be thrown as a part of the function feature. The Exception thrown by the subclass Declaration must be a subset of the parent class.



You can add the declaration of throwing ExceptionB to the foo method of the Base class. However, this destroys the open-close principle. In addition, sometimes we cannot modify the parent class, for example, when reloading a class in Jdk.



Another possible practice is to catch ExceptionB In the foo method of Extend, construct a regiontiona, and throw it. This is a feasible approach, but it is only a matter of expediency.



If RuntimeException is used, none of these problems will exist. This shows that the checked Exception is not a very practical concept. It also means that during programming, we should let our Exception class inherit RuntimeException rather than Exception. (This is the opposite of JDK's suggestion, but practice has proved that the quality of the Code is better .)



For code that needs to handle the checked Exception, you can use a ExceptionAdapter class to wrap the checked Exception into a RuntimeException and throw it. ExceptionAdapter from Bruce Eckel's Does Java need Checked Exception this article, the ExceptionAdapter here is modified according to JDK 1.4:

Public class ExceptionAdapter extends RuntimeException {



Public ExceptionAdapter (Exception ex ){

Super (ex );

}



Public void printStackTrace (java. io. PrintStream s ){

GetCause (). printStackTrace (s );

}



Public void printStackTrace (java. io. PrintWriter s ){

GetCause (). printStackTrace (s );

}



// Rethrow () throws the encapsulated Exception again.

Public void rethrow ()

Throws Exception

{

Throw (Exception) getCause ();

}

}