Is Java today's exception handled?

Exception: refers to an exception event that occurs during a program's operation, such as a 0 overflow, an array out of bounds, a file not found, and so on, which prevents the program from running properly.

(It is important to note that the literal meaning of the exception is different from the usual error, which differs from the design error of the program itself.) At the beginning of the writer has been thinking that if the first time you know the program will be wrong why do it, should not redesign the program? ）

After an exception occurs, Java handles the exception through an object-oriented approach, which is to wrap the error as an object (the objects are all thrown, that is, throw). The system then looks in the call stack of the method, starting with the method that generated the exception, until the appropriate exception-handling method is found, a process known as a catch (catch) exception.

Now let's see what exceptions the system throws:

In Java, exceptions are inherited from the Java.lang.Throwable class, which has two direct subclasses: Error and exception

1.Error class objects, such as dynamic connection errors, hardware plane errors, JVM errors, or low memory, are generated and thrown by the JVM. Typically, Java programs do not handle such exceptions, and the general application is powerless.

The 2.Exception class object, which we typically see with a try, catch processing error, is often called error handling as exception handling (Exception handling). It is also divided into runtime exceptions (runtime Exception), which represent exceptions generated by the Java Virtual machine at runtime, such as the arithmetic operation exception ArithmeticException, Array out-of-bounds exception arrayindexoutofboundsexception, others are non-runtime exceptions, such as input and output exception IOException. The Java compiler requires that a Java program must catch or declare all non-runtime exceptions, but the runtime exception can be handled without processing.

After an exception occurs, there are several ways to handle this:

You can not handle runtime exceptions, catch exceptions with the try-catch-finally statement, declare exceptions through the throws clause, define your own exception class, and throw it with a throw statement.

1. Runtime exception: The program is detected at run time, it may occur in any part of the program, and its number may be large, at this time the system will be generated by the exception object to the default exception handler, on the standard output display the contents of the exception and where the exception occurred.

2. Catch the exception, i.e. try-catch-finally:

try{

Java statements

}catch (ExceptionType1 exceptionobject) {

Exception Handling

}catch (ExceptionType2 exceptionobject) {

Exception Handling

}.....

}finally{

Final handling

}

Specify a piece of code with curly braces {} After try, indicating that the code may throw one or more exceptions;

The parameters of a catch statement are declarations of similar methods, including an exception type and an exception object. , a catch statement can have one or more, and at least one catch statement or finally statement ;

The finally statement can specify a piece of code, regardless of whether the program specified by the try throws an exception, or if the exception type of the catch statement is consistent with the type of exception being thrown, and the code specified by finally is executed, providing a uniform exit.

3. Exception throw: The throw statement is implemented, the format is throw throwableobject;

Where Throwableobject must be an object of the Throwable class or its subclasses.

You can also define your own exception class and throw it with a throw statement. There is much to be said about the use of throw and throws, and I will describe it in detail in the next article.

In general, Java's exception handling mechanism treats the exception event as an object, using the class hierarchy to treat multiple exceptions with the same parent class, and to distinguish different exceptions from each other, with flexibility.

But the recommendation: 1. Exception control is not designed to replace some simple tests

2. Do not overdo the anomaly, so as not to cause waste of resources.

3. Do not close the exception

4. For a custom exception class, it is usually used as a subclass of the exception class, not as a subclass of the error class. and defining the class name often ends with exception.

The use of exception handling mechanism is worth thinking about, to do at the right time to use the appropriate exception handling, and these are in the practice of summing up the basis to get their own experience!

Is Java today's exception handled?