Java Exceptions overview

I. Exceptions in Java overview 1.1Java exception structure

Throwable can be used to represent any class that can be thrown as an exception. Throwable objects derive two types: Error and exception, which are used to denote compile-time and system errors, which programmers often do not care about, and which are basic types that can be thrown, requiring the programmer's attention. RuntimeException are derived classes of exception, and different points are described in the 2.2 and 2.3 summaries.

Java Exceptions (Exception) can be divided into check-type exceptions (checkedexception) and non-checked exceptions (uncheckedexception) in terms of compiler checks.

1.2 Check-type exception (checkedexception)

All exception that are not runtimeexception derived in Java are check-type exceptions. The function declaration of a function must contain a throws statement when there is an operation that throws a check-type exception. A function that invokes a function must also handle the exception, and if it is not processed, it must declare the throws statement on the calling function.

The check-type exception is the first in Java, and it is mandatory to handle the exception at compile time. A large number of exceptions in JDK code are check-type exceptions, including Ioexception,sqlexception, and so on.

1.3 Non-Check type exception (uncheckedexception)

All runtimeexception derived classes in Java are non-check exceptions, and a non-checked exception that is thrown relative to a check exception can not add a throws statement to the function declaration, nor does it need to be forced on the calling function.

Common nullpointexception,classcastexception are common non-checked exceptions. Non-checked exceptions can be handled without try...catch, but if an exception is generated, the exception is handled by the JVM. For RuntimeException subclasses it is best to also use exception handling mechanisms. Although runtimeexception exceptions can be handled without the use of Try...catch, if an exception occurs, it is sure to cause the program to break execution, so in order to ensure that the program can still execute after the error, it is best to use try when developing the code ... The exception handling mechanism for catch is processed.

1.4 Keywords for exceptions

Java exception handling involves five keywords, namely: try, catch, finally, throw, throws

The related syntax of the five keywords is slightly.

Second, exception handling mode 2.1 abnormal chain

In later versions of JDK1.4, the Throwable class supports the exception chaining mechanism. Throwable contains a snapshot of the thread execution stack when its thread was created. It also contains a message string that gives more information about the error. Finally, it can also contain cause (reason): Another throwable that causes this throwable to be thrown. It is also known as the anomaly chain facility, because cause itself also has cause, and so on, it forms an exception chain, each exception is caused by another exception.

In layman's words, the exception chain is to wrap the original exception as a new exception class, and to encapsulate the original exception class in the new exception class, in order to find the root cause of the exception.

2.2 Translation of anomalies

Exception translation is the process of converting an exception to another new exception and then throwing it, the purpose of which is to unify the different types of exceptions appearing in the system in order to facilitate the uniform processing of exceptions.

In most cases, the translated "result exception" type is a custom exception, and the "original exception" needs to be placed in the exception chain during the exception translation.

2.3 Custom Exceptions

A custom exception is a self-written exception class that inherits exception or RuntimeException. The purpose of implementing a custom exception can be broadly divided into the following three types:

1. Use a uniform type to identify multiple different types of exceptions.

2. Better information delivery when anomalies occur. The common means is to define the exception code, exception information, environment objects and other fields in the exception.

3. Convert the check-type exception to a non-checked exception.

Three-Exception handling 3.1 controversy over check-type anomaly and non-check type anomaly

The timing of the use of checked and non-checked exceptions during the actual programming process has been generated from the day the Java language was generated.

The most official version can be found in one of Java's most core designers Joshua Bloch's "Effective Java" Exception usage chapter, his contention is: Use a check-type exception for recoverable situations, use a run-time exception for programming errors.

Although the above-mentioned statement is of "Royal blood", in fact, it seems to me that Java's check-type anomaly is a very unsuccessful work, because the inspection type anomaly has the super "pollution", its appearance brings the trouble far more than the benefit. My view is that check-type exceptions should not be used in almost all cases. When you encounter a situation where a check-type exception cannot be handled, you should use the exception translation to cast the non-checked exception again. I am very excited to see that this view is described in detail by the author on Think in Java 4th edition.

Java's intention to create an inspection-type anomaly is to force programmers to handle exceptions at compile time, which makes the program more robust and reliable, but the Java author forgets: good programming languages help programmers write good programs, but no matter which language avoids programmers using it to write bad programs.

The key point for exception handling is not to check for exceptions at compile or run time, but exceptions must be checked and a uniform, consistent exception checking and processing model needs to be established.

3.2 My exception handling principle

1. Handle only the exceptions that are currently handled.

2. Use exception translation for all check-type anomalies.

3. All custom exceptions are non-check exceptions.

4. Abnormal processes are separated from normal processes and treated as uniformly as possible.

5. Log is not logged in the catch block of the non-exception handling module as much as possible.

6. The catch block should not be empty or appear e.printtrace unless you are doing a resource release operation

7. Complex operations cannot occur in a finally block, and no exception can be thrown and return cannot occur.

3.3 The general way I handle exceptions

1. Treat the throw statement as the starting point of the exception process, and treat the exception object as a data carrier in the normal process to the abnormal process transition.

2. Create a unified custom exception type to wrap all check-type exceptions.

3. In most cases, only a unique anomaly capture point is established on the backbone of the program, and the received exception is processed at that point.

Java Exceptions overview