Shulou(Shulou.com)06/02 Report--

Java how to use Throwable Error and Exception to handle exceptions, I believe that many inexperienced people do not know what to do, so this article summarizes the causes of the problem and solutions, through this article I hope you can solve this problem.

What is an anomaly?

The abnormal English word is exception, which literally translates to "accident, exception", that is, abnormal situation. In fact, exceptions are essentially program errors, including program logic errors and system errors. Such as the use of empty references, array subscript crossing bounds, memory overflow errors, and so on, these are unexpected situations that deviate from the intention of our program itself. Errors often occur in the process of writing a program, including errors during compilation and running. Errors that occur during compilation are corrected by the compiler, but run-time errors are beyond the compiler's power. and run-time errors are often unpredictable. If an error occurs while the program is running, if ignored, the program will terminate or directly cause the system to crash, which is obviously not the result we want to see. Therefore, how to deal with and remedy the errors that occur during the run? Java provides an exception mechanism for handling, through the exception mechanism to handle errors that occur during the run of the program. Through the exception mechanism, we can better improve the robustness of the program.

Unchecked exception (non-checked exception)

Also known as runtime RuntimeException, such as the common NullPointerException, IndexOutOfBoundsException. For run-time exceptions, the java compiler does not require exception catching or declaration, which is up to the programmer.

Checked exception (check for exceptions, compile exceptions)

Also known as non-run-time exceptions (exceptions other than run-time exceptions are non-run-time exceptions), the java compiler forces programmers to capture processing, such as the common IOExeption and SQLException. The compilation will not pass without catching or throwing a declaration for a non-runtime exception.

Throwable

There are two important subclasses: Exception (exception) and Error (error), both of which are important subclasses of Java exception handling, each containing large quantum classes.

Error (error)

Is an error that the program cannot handle and indicates a serious problem in running the application. Most errors have nothing to do with the actions performed by the code writer and represent problems with the JVM (Java virtual machine) when the code is running. For example, a Java virtual machine running error (Virtual MachineError) occurs when the JVM no longer has the memory resources needed to continue the operation. When these exceptions occur, the Java virtual machine (JVM) generally chooses thread termination. These errors indicate that the failure occurred in the virtual machine itself, or when the virtual machine attempted to execute the application, such as Java virtual machine running error (Virtual MachineError), class definition error (NoClassDefFoundError), and so on. These errors are untraceable because they are outside the control and processing power of the application, and the vast majority are conditions that are not allowed to occur while the program is running. For a well-designed application, even if an error does occur, you should not essentially try to deal with the exception caused by it. In Java, errors are described by a subclass of Error.

Exception (exception)

Is an exception that the program itself can handle. The Exception class has an important subclass, RuntimeException. The RuntimeException class and its subclasses represent errors raised by "common operations of JVM". For example, if you attempt to use a null object reference, a divisor of zero, or an array out of bounds, run-time exceptions (NullPointerException, ArithmeticException) and ArrayIndexOutOfBoundException are thrown, respectively.

Difference

Note: the difference between exceptions and errors: exceptions can be handled by the program itself, while errors cannot be handled. In general, Java exceptions (including Exception and Error) are divided into detectable exceptions (checked exceptions) and untraceable exceptions (unchecked exceptions).

Searchable exception (exception that the compiler requires that must be handled): a reasonable exception that can easily occur when a correct program is running. Although the detectable anomaly is an abnormal condition, its occurrence is predictable to a certain extent, and once this abnormal condition occurs, it must be dealt with in some way.

Except for RuntimeException and its subclasses, other Exception classes and their subclasses are detectable exceptions. The characteristic of this exception is that the Java compiler will check it, that is, when such an exception may occur in the program, either catch it with the try-catch statement or declare that it is thrown with the throws clause, otherwise the compilation will not pass.

Should catch what?

In fact, as long as Throwable and its subclasses can both throw and catch, should we catch (Throwable th) or catch (Exception) where we need to handle exceptions uniformly?

The difference between these two processes is that catch throwable captures Error and other classes that inherit Throwable. On the other hand, catch Exception only captures Exception and its subclasses, and the scope of capture is even smaller. Regardless of the fact that other classes inherit Throwable, the first catch captures Error and its subclasses more than the second catch.

So does Error need to be captured? As mentioned in the comments for the Error class in JDK (below), Error is a serious problem that applications should not capture.

An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch. Most such errors are abnormal conditions. The ThreadDeath error, though a "normal" condition, is also a subclass of Error because most applications should not try to catch it.

A method is not required to declare in its throws clause any subclasses of Error that might be thrown during the execution of the method but not caught, since these errors are abnormal conditions that should never occur.

It is also mentioned in Java Lanuage Spec 7 that Error inherits from Throwable rather than Exception, so that programs can use "catch (Exception)" to catch exceptions without catching Error, because some recovery work can be done after the occurrence of Exception, but it is generally unrecoverable after the occurrence of Error.

The class Error is a separate subclass ofThrowable, distinct from Exception in the class

Hierarchy, to allow programs to use the idiom "} catch (Exception e) {" (§11.2.3)

To catch all exceptions from which recovery may be possible without catching errors from which recovery is typically not possible.

It is not difficult to see that the design idea of Java itself is to hope that catch Exception is enough. If there is an Error, catch will not have any effect.

Can Error be catch? Can I do something else after catch?

Error can be catch, and can also be handled like regular Exception, and even if not captured, it will only cause the current thread to hang, other threads can still run normally, and you can do some other processing after capturing Error if necessary. But Error is an internal error, unlike Exception, it is possible that program and business errors are recoverable.

After reading the above, have you mastered how to use Throwable Error and Exception to handle exceptions in java? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.