Exceptions in Java

Exceptions in Java Grandpa Class for Throwable, he has two sons Error and Exception

All exceptions in Java inherit the Java.lang.Throwable class

Error: Indicates an unexpected error detected by the JVM virtual machine, because this is a serious error at the JVM level, which prevents the JVM from continuing, so this is not a snap and cannot take any recovery action, at most, only error messages can be displayed. The error class system describes the internal errors and resource exhaustion scenarios in the Java operating system. Applications should not throw objects of this type (typically thrown by virtual machines). In the event of such an error, there is no other way of doing anything other than trying to get the program safely out.

Exception: Represents recoverable exceptions, which can be captured. Java provides two main types of exceptions:runtime exception and checked exception. Exception Exception are classified as run-time exceptions (RuntimeException) and non-runtime exceptions, also known as non-check exceptions (unchecked Exception) and check exceptions (Checked Exception).

An exception represents an unhealthy state that may occur during a program's run, and a run-time exception that represents an exception that may be encountered in a typical operation of a virtual machine is a common run error. The Java compiler requires the method to declare a non-runtime exception that might occur, but does not require that a runtime exception that is not caught to be thrown must be declared.

The exception types that are inspected for exceptions (checked exception) and non-inspected exceptions (unchecked exception). Non-examined exceptions refer to the Java.lang.RuntimeException and Java.lang.Error classes and their subclasses, and all other exception classes are referred to as inspected exceptions. There is no difference between the two types of exceptions, and the only difference is that the legality of using an exception is checked by the compiler at compile time. Because of this, the exception being inspected requires more code than the non-inspected exception to avoid compilation errors.

  has always been about whether to use the exception in the program or not to be inspected
exception, there has been a controversy between developers, after all, both types of anomalies have advantages and disadvantages. The exception is characterized by the fact that it forces the developer to explicitly declare and capture in the code, otherwise a compilation error is generated. This restriction, on the good side, prevents the developer from accidentally ignoring certain errors, because the compiler does not allow unhandled exceptions to be handled, and in bad terms, the exception is a higher requirement for the design of the program. Improper use of the inspected exception will cause the code to be flooded with code that is not actually useful, just to be added by compiling. Rather than the exception being examined, the exception is that if you do not catch an exception, there will be no compilation errors and exceptions will be thrown at run time.

The prevailing opinion is that it is preferable to use non-inspected exceptions first.

The checked exception is the IO exception that we often encounter, and the SQL exception is the exception. For this exception, the Java compiler enforces that we must catch the exceptions that occur. So, in the face of such anomalies whether we like it or not, we can only write a lot of catch blocks to deal with possible exceptions. Such exceptions are generally external errors, such as attempting to read data from the end of a file, which is not an error in the program itself, but an external error that occurs in the application environment. But another exception: Runtime exception, also known as runtime exceptions, we can not handle. When such an exception occurs, it is always taken over by the virtual machine. For example: No one has ever dealt with a nullpointerexception exception, which is a run-time exception, and this exception is one of the most common exceptions. The runtimeexception system includes wrong type conversions, array cross-border access, and attempts to access null pointers, and so on. The principle of dealing with runtimeexception is that if runtimeexception is present, it must be a programmer's fault. For example, You can avoid array out-of-bounds access exceptions by examining array subscripts and arrays boundaries. After a run-time exception, the system throws the exception to the top and continues to encounter processing code. If there is no processing block, to the topmost level, if it is multithreading is thrown by Thread.run (), if it is a single thread is thrown by main (). Once thrown, the thread exits if it is a thread. If the exception is thrown by the main program, then the entire program exits. Runtime exceptions are subclasses of the exception, and there are general exceptions that can be handled by catch blocks. It's just that we're not dealing with him. That is, if you do not handle a run-time exception, then a run-time exception occurs, either the thread aborts or the main program terminates. If you do not want to terminate, you must catch all run-time exceptions and never let the processing thread exit. Abnormal data in the queue, the normal processing should be to discard the abnormal data, and then log. The handling of normal data should not be affected by abnormal data. This can be a good application in this scenario, but it does not mean that you should do so in all scenarios. If, in other scenarios, you encounter some errors, if you exit the program better, then you can ignore the runtime exception, or by the exception of the handling of explicit control program exit. One of the goals of exception handling is to recover the program from the exception.

1.The Java exception architecture looks like this:

Exceptions in Java