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

This article mainly introduces "what are the important error handling mechanism anomalies in Java". In daily operation, I believe many people have doubts about the important error handling mechanism anomalies in Java. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful to answer the doubts about "what are the important error handling mechanism anomalies in Java?" Next, please follow the editor to study!

I. introduction of exceptions

What is an anomaly?

Exception refers to the program in the process of running, due to external problems caused by the program running abnormal events, the occurrence of exceptions will often interrupt the operation of the program. In Java, an object-oriented programming language, everything is an object, and the exception itself is also an object. When an exception occurs in the program, it will produce an exception object.

Classification of anomalies

Throwable

As you can see from the figure, exceptions are mainly composed of the following categories:

Throwable

Error

Exception

Next, we will introduce the role of these base classes respectively.

Throwable

The Throwable class is the top-level parent of all errors or exceptions in the Java language, and other exception classes inherit from this class. The Throwable class has two important subclasses: * * Exception (exception) * * and "Error", both of which are important subclasses of Java exception handling, each containing large quantum classes.

Can be thrown through a Java virtual machine or Java throw statement only if the object is an instance of this class or its subclass. Similarly, only this class or its subclasses can be parameter types in the catch clause.

The Throwable object contains a snapshot of the thread execution stack when its thread is created, as well as a message string that gives more information about the error.

Finally, it can also contain a cause (reason): another throwable that causes this throwable to throw. This cause facility first appeared in version 1.4. It is also known as the exception chain facility because the cause itself has cause, and so on, forming an exception chain, with each exception caused by another exception.

Error

Error is a subclass of Throwable, and in general, applications "should not try to capture serious problems."

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: Java virtual machine running error (Virtual MachineError), OutOfMemoryError 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 and its subclasses represent various unexpected events sent when the program is running. It can be used by Java exception handling mechanism and is the core of exception handling.

There are two main types of Exception exceptions:

"1. Non-inspecting exception (unchecked exception)"

Error and RuntimeException and their subclasses. The Java language does not prompt and find such exceptions when compiling, and does not require them to be handled in the program. So we can write code in the program to deal with (using try... Catch... Finally) may not be handled at all. For these errors or exceptions, we should fix the code instead of handling them through the exception handler. Most of the reason for such exceptions is that there is something wrong with our code logic.

For example:

When a number is divided by 0 in the program, an ArithmeticException exception is thrown

During type conversion, an incorrect cast throws a ClassCastException type conversion exception

An ArrayIndexOutOfBoundsException exception is thrown when an array index is out of bounds using a collection

When the program uses a null object for operation, it will throw an annotated null pointer NullPointerException exception and so on.

Common non-inspecting exceptions are:

Exception description ArithmeticException throws an exception when the operation condition of the exception occurs. For example, when an integer is divided by zero, an instance of this class is thrown. The exception that ArrayIndexOutOfBoundsException runs when accessing an array with an illegal index. If the index is negative or greater than or equal to the array size, the index is illegal. The exception that is thrown when ArrayStoreException attempts to store objects of the wrong type into an array of objects. The exception that is thrown when ClassCastException attempts to cast an object to an instance that is not of the same type or its subclass. IllegalArgumentException throws this exception when an illegal or incorrect parameter is passed to a method. IllegalMonitorStateException throws this exception when a thread has tried to wait for an object's monitor, or notifies other threads that are waiting for the object monitor, and the thread itself does not get the specified monitor. A signal generated by IllegalStateException when a method is called at an illegal or inappropriate time. In other words, the Java environment or application is not in the appropriate state required by the request operation. This exception is thrown when the IllegalThreadStateException thread is not in the appropriate state required by the requested operation. IndexOutOfBoundsException the exception that is thrown when the index of a sort is out of range, for example, the sort of an array, a string, or a vector. NegativeArraySizeException throws this exception if the application attempts to create an array of negative size. NullPointerException throws this exception when the application needs to manipulate the object and the object instance is null. NumberFormatException throws this exception when an application attempts to convert a string to a numeric type, but the string cannot be converted to the appropriate format. SecurityException an exception thrown by the security manager that indicates a security violation. StringIndexOutOfBoundsException this exception is thrown by the String method, indicating that the index is negative or exceeds the size of the string.

"2. Inspecting exception (checked exception)"

Except for Error and RuntimeException. The Java language forces programmers to prepare for such exceptions (using try. Catch... Finally or throws). In the method, either use the try-catch statement to capture it and process it, or declare to throw it with the throws clause, otherwise the compilation will not pass. Such exceptions are generally caused by the environment in which the program is running. Because the program may be run in a variety of unknown environments, and the programmer cannot interfere with how the user uses the program he writes, the programmer should always be prepared for such exceptions. Such as SQLException,IOException,ClassNotFoundException, etc.

Checked exceptions are those exceptions that the compiler requires to be handled during compilation, and you have to handle them at compile time.

Common inspection exceptions are:

Exception description ClassNotFoundException throws an exception when an application tries to load a class and finds that there is no definition of the class by name. CloneNotSupportedException throws this exception when it clones an object and finds that the object does not implement the Cloneable interface. IllegalAccessException throws this exception when an application attempts to access classes, member variables, or calling methods through reflection, but cannot access the definitions of those classes, member variables, or methods. InstantiationException throws this exception when it attempts to create an instance of a class using the newInstance method in the Class class, and the specified class object cannot be instantiated because it is an interface or an abstract class. InterruptedException this exception is thrown when one thread is interrupted by another. NoSuchFieldException throws the exception when the specified variable field is not found, and NoSuchMethodException throws the exception when the specified class method is not found.

Second, the initial recognition of anomalies

Let's give you a more intuitive understanding of the Java exception through a simple example.

The following code throws the famous null pointer exception: NullPointerException.

Public class Test {private int a = 1; private int b = 2; public static void main (String [] args) {Test T1 = new Test (); Test T2 = null; System.out.println (t 1.a); System.out.println (t 2.a); System.out.println (t 2.c ()) } public String c () {return "Wechat official account: I am developer FTD";}}

Run the program, and the output from the console is as follows:

1 Exception in thread "main" java.lang.NullPointerException at cc.devclub.ftd.Test.main (Test.java:11) Process finished with exit code 1

As you can see from the console output, the program prints "1", then throws "java.lang.NullPointerException" at line 11 of the program, and the program stops running.

Third, exception handling mechanism

When writing code to handle exceptions, there are two different ways to handle inspecting exceptions:

Use "try …" Catch... Finally... "statement block processing

Use the keyword "throws/throw" in the method to leave the exception to the method caller to handle

Try...catch...finally... Keyword

Exceptions can be caught using the try and catch keywords.

The try/catch code block is placed where the exception may occur.

The code in the try/catch code block is called protection code, and the syntax for using try/catch is as follows:

Try {...} catch (IOException ioException) {...} catch (Exception exception) {...} finally {...}

"try block:"

Put the code that may cause an exception in the try block.

If you finish executing the try and no exception occurs, then go on to execute the code in the finally block and the code after the finally, if any.

If an exception occurs in the program, try to match the corresponding catch block.

"catch block:"

Each catch block is used to catch and handle a specific exception, or a subclass of this exception type. Multiple exceptions can be declared in a catch in Java7.

The parentheses after the catch define the exception type and exception parameters. If the exception matches and is the first to match, the virtual machine uses this catch block to handle the exception.

You can use the exception parameters of this block in the catch block to get information about the exception. Exception parameters are local variables in this catch block and cannot be accessed by other blocks.

If the exception that occurs in the current try block is not caught in all subsequent catch, execute the finally first, and then match the exception handler to the external caller of the method.

If no exception occurs in the try, all catch blocks are ignored.

"what you need to pay attention to."

1. Local variables in try block, local variables in catch block (including exception variables), and local variables in finally can not be shared.

2. Each catch block is used to handle an exception. Exception matching is found from top to bottom in the order of catch blocks, and only the first matching catch is performed. When matching, not only exact matching is run, but also parent matching is supported. Therefore, if multiple try exception types under the same catch block have a parent-child relationship, you should put the subclass exception before the parent exception, so as to ensure that each catch block has a meaningful existence.

3. In Java, the task of exception handling is to transfer the execution control flow from the place where the exception occurs to the place where the exception can be handled. That is to say: when an exception occurs in a statement of a method, the statement that follows the statement will no longer be executed and it loses focus. The execution flow jumps to the nearest matching exception handling catch code block to execute, and after the exception is handled, the execution flow then executes after the "catch code block that handled the exception."

"finally block:"

Finally blocks are not required and are usually optional.

The code in finally executes regardless of whether or not the exception occurs and whether the exception match is handled.

A try must have at least one catch block, otherwise there must be at least 1 finally block. But finally is not used to handle exceptions, finally will not catch and handle exceptions, exceptions can only be handled by catch blocks.

Finally mainly does some cleaning work, such as closing the stream, closing the database connection and so on.

Finally block whether an exception occurs or not, as long as the corresponding try executes, it must also execute. There is only one way to prevent the finally block from executing: "System.exit ()".

You need to develop * * good programming habits: * * Open resources in try blocks, clean up and release these resources in finally blocks to avoid memory leaks.

"need to pay attention to:"

1. In the same try... Catch... Finally... Block, if an exception is thrown in the try and there is a matching catch block, the catch block is executed first, followed by the finally block. If there is no catch block match, finally is executed first, and then go to the upper caller to find the appropriate catch block.

2. In the same try... Catch... Finally... Block, an exception occurs in try, and an exception is thrown when the exception is handled in the matching catch block, then the subsequent finally will also execute: first execute the finally block, and then go to the upper caller to find the appropriate catch block.

Throws/throw keyword

"throws keyword"

If the code inside a method throws checked exception, and the method itself does not fully handle these exceptions, java's compiler will require you to declare these possible exceptions with the "throws" keyword on the method's signature, otherwise the compilation will fail.

Throws is another way to handle exceptions, unlike try. Catch... Finally... The throws keyword simply throws an exception that may occur in the method to the caller, but does not specifically handle it

The reason for this exception handling may be that the method itself does not know how to handle such an exception, or that the caller handles it better, and the caller is responsible for the possible exception.

"throw keyword"

We can also manually explicitly throw an exception through the throw statement, and the throw statement must be followed by an exception object. The syntax is as follows:

Throw exceptionObject

The throw statement must be written in the method, and the place where the throw statement is executed is an exception throwing point, which is no different from the exception throwing point automatically generated by JRE.

Public void save (User user) {if (user = = null) throw new IllegalArgumentException ("User object is empty"); / /. }

Execution order of try-catch-finally

Questions related to the execution order of try-catch-finally can be said to be "regulars" in various interviews, especially if there is a return statement in the finally block. Let's look directly at a few interview questions:

"interview question 1:"

Public static void main (String [] args) {int result = test1 (); System.out.println (result);} public static int test1 () {int I = 1; try {iLaught; System.out.println ("try block, I =" + I);} catch (Exception e) {iMuy; System.out.println ("catch block i =" + I) } finally {I = 10; System.out.println ("finally block i =" + I);} return I;}

You might as well calculate what the programmer will run in the end.

The output is as follows:

Try block, I = 2 finally block i = 10 10

This is a fairly simple question, there is no pit, let's change it a little bit:

Public static int test2 () {int I = 1; try {iwhisy; throw new Exception ();} catch (Exception e) {Imura; System.out.println ("catch block i =" + I);} finally {I = 10; System.out.println ("finally block i =" + I);} return I;}

The output is as follows:

Catch block i = 1 finally block i = 10 10

The running result must be expected. The program throws an exception, which is then caught and handled by the catch block of this method.

"interview question 2:"

Public static void main (String [] args) {int result = test3 (); System.out.println (result);} public static int test3 () {/ / try statement block with return statements in the overall execution order int I = 1; try {istatements; System.out.println ("try block, I =" + I); return I;} catch (Exception e) {isentences + System.out.println ("catch block i =" + I); return I;} finally {I = 10; System.out.println ("finally block i =" + I);}}

The output is as follows:

Try block, I = 2 finally block i = 10 2

Are you a little confused? Why did I end up executing the code in the try block when I knew there was a return statement in the finally block?

Let's decompile this class and look at the implementation of the compiled bytecode of the test3 method:

0: iconst_1 / / load 1 into Operand stack 1: istore_0 / / store elements at Operand stack 0 in local variable table 2: iinc 0 1 / / add the elements of the 0 position of the local variable table directly (iTun2) 5: getstatic # 3 / / 5-27 println method 8: new # 5 11: dup 12: invokespecial # 6 15: ldc # 7 17: invokevirtual # 8 20: iload_0 21: invokevirtual # 9 24: invokevirtual # 10 27: invokevirtual # 11 30: iload_0 / / load the elements of the local variable table position 0 into the operation Stack (2) 31: istore_1 / / store the elements at the top of the operation stack at position 1 32: bipush 10 / / load a constant to the operation stack (10) 34: istore_0 / / store 10 into the local variable table 0 35: getstatic # 3 / / 35-57 execute println method 38: new # 5 in finally 41: dup 42: invokespecial # 6 45: ldc # 12 47: invokevirtual # 8 50: iload_0 51: invokevirtual # 9 54: invokevirtual # 10 57: invokevirtual # 11 60: iload_1 / / change the position of table 1 locally The element is loaded into the operation stack (2) 61: ireturn / / returns the element at the top of the operation stack (2)-try + finally end-- here is catch + finally Similar-62: astore_1 63: iinc 0,1. .

As we can see from our analysis, the content in the finally block is always executed, regardless of whether the program has an exception or not. The reason is that "the compiler will make two copies of the code in the finally block and add it after try and catch, respectively."

Some people may wonder that our I was originally stored in the local variable table 0 position, and in the end, the code in finally did fill the slot 0 position with the value 10, but why did the program still return the value 2?

If you look at the bytecode carefully, you will find that before the return statement returns, the virtual machine will press the value to be returned into the Operand stack and wait for it to return. Even if the finally statement block has modified I, the value to be returned does exist in the Operand stack, so it will not affect the result returned by the program.

"interview question 3:"

In the public static int test4 () {/ / finally statement block, there are return statements int I = 1; try {ilegs; System.out.println ("try block, I =" + I); return I;} catch (Exception e) {itrees; System.out.println ("catch block i =" + I); return I;} finally {iframes + System.out.println ("finally block i =" + I); return I;}}

Running result:

Try block, I = 2 finally block i = 3 3

In fact, you look at the whole process from its bytecode instructions, rather than just memorizing its execution.

You will find that the program will eventually return with the return statement in the finally code block and directly ignore the return instruction in the try statement block.

Custom exception

All the exceptions defined in Java's exception mechanism cannot foresee all possible errors, and in some specific situations, we need to customize the exception type to report some error messages up.

Customizing exception types is also quite simple. You can choose to inherit Throwable,Exception or their subclasses, or you don't even need to implement and override any methods of the parent class to define an exception type.

For example:

Public class MyException extends RuntimeException {} public class MyException extends Exception {}

According to international practice, a custom exception should always contain the following constructor:

A no-parameter constructor

A constructor with a String argument and passed to the constructor of the parent class.

One takes a String parameter and a Throwable parameter and is passed to the parent class constructor

A constructor with a Throwable argument and passed to the constructor of the parent class.

The following is the complete source code for the IOException class, which we can refer to:

Public class IOException extends Exception {static final long serialVersionUID = 7818375828146090155L; public IOException () {super ();} public IOException (String message) {super (message);} public IOException (String message, Throwable cause) {super (message, cause);} public IOException (Throwable cause) {super (cause);}}

Abnormal precautions

1. When a subclass overrides a function with a throws declaration of a parent class, the exception declared by its throws must be within the controllable range of the parent class exception-the exception handler used to handle the parent class's throws method must also be applicable to the subclass's throws method. This is to support polymorphism.

For example, if the parent class method throws has 2 exceptions, the subclass cannot throws 3 or more exceptions. For the parent class throws IOException, the subclass must be a subclass of throws IOException or IOException.

2. Java programs can be multithreaded. Each thread is an independent execution flow and a separate function call stack. If the program has only one thread, an exception that is not handled by any code will cause the program to terminate. If it is multithreaded, an exception that is not handled by any code will only cause the thread in which the exception is located to end.

In other words, the exception in Java is thread-independent, and the thread's problem should be solved by the thread itself, not delegated to the outside, and will not directly affect the execution of other threads.

Common errors in the use of exceptions

1. Display the exception directly on the page or client

It is common to print exceptions directly to the client. Once an exception occurs when the program is running, the container prints the exception stack information directly on the page by default. From the customer's point of view, any exception has no practical significance, and the vast majority of customers do not understand the exception information at all, and software developers should try their best to avoid presenting the exception directly to the user. be sure to encapsulate the exception in the front-end display layer. At present, the vast majority of applications are front-end separation mode, this direct printing exception situation has been relatively improved, but we should pay special attention to this principle when coding.

2. Ignore exceptions

The following exception handling simply outputs the exception to the console and does not make any sense. And the exception here does not interrupt the program, and the call code continues to execute, resulting in more exceptions.

Public void retrieveObjectById (Long id) {try {/.. some code that throws SQLException} catch (SQLException ex) {/ * anyone who knows that the exception printing here is meaningless, just outputs the error stack to the console. * in a Production environment, you need to output the error stack to the log. * and here the program continues to execute after catch processing, which will lead to further problems * / ex.printStacktrace ();}}

Catching an exception without handling it is a big taboo when writing code, which can be reconstructed:

Public void retrieveObjectById (Long id) {try {/.. some code that throws SQLException} catch (SQLException ex) {throw new RuntimeException ("Exception in retieveObjectById", ex);} finally {/ / clean up resultset, statement, connection etc}}

3. Include the exception in the loop statement block

As shown in the following code, the exception is contained in the block of for loop statements.

For (int I = 0; I < 100; iTunes +) {try {} catch (XXXException e) {/ /.... }}

We all know that exception handling takes up system resources. At first glance, everyone thought that such a mistake would not be made. On the other hand, class An executes a loop in which the method of class B is called, while the method called in class B contains a block of statements such as try-catch. Remove the class hierarchy and the code is the same as above.

4. Use Exception to catch all potential exceptions

During the execution of a method, several different types of exceptions are thrown. For the sake of code brevity, use the base class Exception to catch all potential exceptions, as shown in the following example:

Public void retrieveObjectById (Long id) {try {/ /... Throw the IOException code call / /... The code that throws the SQLException calls} catch (Exception e) {/ / all potential exceptions caught by the base class Exception here. If caught in this way by multiple levels, the valid information of the original exception throw new RuntimeException ("Exception in retieveObjectById", e);}} will be lost.

It is estimated that most programmers will write this way. In order to save trouble and make it easy, a top-level exception is used to capture all possible exceptions. Although the exception is guaranteed to be caught, the program cannot correctly handle different error exceptions and can be reconstructed:

Public void retrieveObjectById (Long id) {try {/ /.. some code that throws RuntimeException, IOException, SQLException} catch (IOException e) {/ / only capture IOException throw new RuntimeException (/ * specify the error code * / code, "Exception in retieveObjectById", e) corresponding to the IOException here. } catch (SQLException e) {/ / only capture SQLException throw new RuntimeException (/ * specify the error code * / code, "Exception in retieveObjectById", e) corresponding to SQLException here;}}

5. The information contained in the exception can not fully locate the problem.

Exceptions should not only let developers know what went wrong, but more often developers need to know what caused the problem. We know that java .lang.exception has a constructor for string type parameters, which can be customized into easy-to-understand prompts.

Simple custom information developers can only know where the exception occurred, but in many cases, developers need to know what parameters caused such an exception. At this point, we need to append the parameter information of the method call to the custom information. The following example lists the case of only one parameter, and in the case of multiple parameters, you can write a separate tool class to organize such a string.

Public void retieveObjectById (Long id) {try {/.. some code that throws SQLException} catch (SQLException ex) {/ / add parameter information to the exception information throw new RuntimeException ("Exception in retieveObjectById with Object Id:" + id, ex);}} at this point, the study on "what are the important error handling mechanism exceptions in Java" is over, hoping to solve everyone's doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

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.