Java errors and exceptions

 Java exception structure diagram

 

 

In Java, all exceptions have a common ancestor Throwable (throwable). Throwable specifies the commonality of any problem in the code that can be transported through a Java application by the exception propagation mechanism.
  Throwable has two important subclasses: Exception (exception) and Error (error), both of which are important subclasses of Java exception handling, each containing a large number of subclasses.

 
  ①.Exception is a possible predictable and recoverable problem in an application. Generally most abnormalities indicate moderate to mild problems. Exceptions are generally generated under specific circumstances, usually in specific methods and operations of the code. In the EchoInput class, an IOException may occur when trying to call the readLine method.
    The Exception class has an important subclass, RuntimeException. The RuntimeException class and its subclasses represent errors thrown by "common JVM operations". For example, an attempt to use a null-valued object reference, division by zero, or array out-of-bounds throws a runtime exception (NullPointerException, ArithmeticException) and ArrayIndexOutOfBoundException, respectively.
  ②.Error (error) indicates a serious problem in running the application. Most errors have nothing to do with what the author of the code did, but rather represent a problem with the JVM (Java Virtual Machine) when the code is running. For example, an OutOfMemoryError occurs when the JVM no longer has the memory resources to continue the operation. 

 

The division of checked and unchecked exceptions

 

Exceptions in Java are divided into two categories:
  1.Checked Exception (non-Runtime Exception)
  2. Unchecked Exception (Runtime Exception)
Runtime exception
 RuntimeException class is a subclass of Exception class, it is called runtime exception, all runtime exceptions in Java All time exceptions inherit directly or indirectly from the RuntimeException class.
  In Java, all exceptions that inherit from Exception but not from RuntimeException are non-runtime exceptions.
  A try can be followed by multiple catches, but no matter how many, at most one catch block will be executed.

For non-runtime exceptions (checked exceptions), they must be handled, otherwise the compilation will fail.
  There are two processing methods:
  1. Use try..catch..finally to catch;
  2. Write throws an Exception type after the method declaration that generates the exception, such as throws Exception, and throw the exception to the outer layer.
For runtime exceptions, it may or may not be handled. It is recommended not to handle runtime exceptions.

 

 

  • Throwable: divided into two categories

    • Exception: Possible predictable, recoverable problem in the application
      • Checked Exception (non-Runtime Exception): It is required to be processed before compilation, try...catch, Java tells you that there may be problems that need to be dealt with.
      • Unchecked Exception (Runtime Exception): An exception is thrown at runtime. Although you can also try...catch, it is not encouraged to use it. It should be to fix the bug that may cause the cause.
    • Error: A more serious problem in the application. Usually indicates a problem with the JVM (Java Virtual Machine) when the code is running. For example: OutOfMemoryError thrown by no more memory resources needed to continue the operation. When encountering such a problem, we can only analyze the cause and prevent it.
  • When custom exception, usually use Exception, to handle this exception.

  • throw 和 throws:

    • throw is used to throw arbitrary exceptions.
    • throws is used in function headers to indicate various exceptions that may be thrown by the member function.
  • try-catch-finally

    • try must be executed
    • catch is executed if there is a caught exception
    • finally must be executed


 

Extension: The difference between errors and exceptions (Error vs Exception) 
  1).java.lang.Error: Subclass of Throwable, used to mark serious errors. Reasonable applications should not go to try/catch this kind of error. The vast majority of errors are abnormal and should never occur.
     java.lang.Exception: A subclass of Throwable, used to indicate a condition that a reasonable program wants to catch. That is, it is only a program operating condition, not a critical error, and user programs are encouraged to catch it.
  2).Error and RuntimeException and their subclasses are unchecked exceptions (unchecked exceptions), while all other Exception classes are checked exceptions (checked exceptions).

    Checked exceptions: usually from a recoverable program thrown, and preferably to be able to use program recovery from such an exception. Such as FileNotFoundException, ParseException, etc. The checked exception occurs in the compilation phase, and try...catch (or throws) must be used, otherwise the compilation will fail.
    unchecked exceptions: Usually exceptions that shouldn't have happened if everything was OK, but did happen. Occurs in the runtime, with uncertainty, mainly due to the logic problems of the program. Such as ArrayIndexOutOfBoundException, ClassCastException, etc. From the perspective of the language itself, the program should not go to catch such exceptions, although it is possible to catch and recover from exceptions such as RuntimeException, but terminal programmers are not encouraged to do so, because it is completely unnecessary. Because such errors are bugs themselves and should be fixed, the program should stop executing immediately when such errors occur. Therefore, in the face of Errors and unchecked exceptions, the program should automatically terminate the execution, and the programmer should not do things such as try/catch, but should find out the reason and modify the code logic.
    RuntimeException: The RuntimeException system includes wrong type conversion, array out-of-bounds access, and attempts to access null pointers, etc.
The principle of dealing with RuntimeException is: If a RuntimeException occurs, it must be the programmer's error. For example, array out-of-bounds access exceptions can be avoided by checking array subscripts and array bounds. Other checked exceptions (IOException, etc.) are generally external errors, such as trying to read data from the end of the file, etc. This is not an error of the program itself, but an external error that occurs in the application environment.

 

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=325360957&siteId=291194637