Thinking Logic of computer programs (25)-Exceptions (bottom)

In the previous section we introduced the basic concepts and exception classes for exceptions, and in this section we'll look at the handling of exceptions, and we'll start by looking at the Java language's support for exception handling, and then explore how exceptions should be handled in practice.

Exception handling

Catch match

The previous section briefly describes the use of Try/catch catch exception, where catch only one, in fact, catch can also have more than one, each corresponding to an exception type, such as:

Try {    // code that could trigger an exception }catch(NumberFormatException e) {    System.out.println ("not valid number");} Catch (RuntimeException e) {    System.out.println ("Runtime exception" +E.getmessage ());} Catch (Exception e) {    e.printstacktrace ();}

The exception handling mechanism will find the first matching catch block based on the type of exception thrown, and after finding the code within the catch block, the other catch blocks will not be executed, and if not found, they will continue to be looked up in the upper method. It is important to note that the exception type thrown is the subclass of the exception that is declared in the catch, so you need to put the most specific subclass in front, and if the base class exception in front, the other more specific catch code will not be executed.

The example also demonstrates the use of exception information, E.getmessage () Gets the exception message, and E.printstacktrace () prints the exception stack to the standard error output stream. This information helps to understand why exceptions occur, which is a common method of solving programming errors. The example is to output information directly to a standard stream, and the more common practice in a real system is to output to a dedicated log.

Re-throw

After processing within the catch block, you can re-throw the exception, which can be original or new, as follows:

Try {    // code that could trigger an exception }catch(NumberFormatException e) {    System.out.println ("not valid number");     Throw New Appexception ("Incorrect input format", e);} Catch (Exception e) {    e.printstacktrace ();     Throw e;}

For exception, after printing out the exception stack, it is re-thrown through throw e.

And for NumberFormatException, we re-throw a appexception, the current exception as cause passed to the appexception, thus forming an anomaly chain, The code captured to Appexception can be numberformatexception by Getcause ().

Why do you want to re-throw it? Because the current code is not able to handle the exception completely, it needs to be handled further by the caller.

Why throw a new exception? Of course, the current exception is inappropriate, inappropriate may be insufficient information, need to add some new information, may be too detailed, not easy for the caller to understand and use, if the caller is interested in the details, you can continue to get the original exception through Getcause ().

Finally

An important part of the anomaly mechanism is finally, the catch can be followed by the finally statement, and the syntax is as follows:

Try {    // could throw exception }catch(Exception e) {    // catch Exception } finally {    // execute with or without exception }

The code in the finally is executed regardless of whether or not an exception occurs. Specifically:

• If no exception occurs, execute after the execution of the code inside the try is complete.
• If an exception occurs and caught by a catch, executes after the execution of the code within the catch is completed
• If an exception occurs but is not captured, it is executed before the exception is thrown to the upper layer.

Because of this feature of finally, it is generally used to release resources such as database connections, file streams, and so on.

In try/catch/finally syntax, catch is not required, that is, you can have only try/finally, which means that exceptions are not caught, exceptions are automatically passed up, but the code in finally is executed after an exception occurs.

The finally statement has an execution detail, and if there is a return statement within a try or catch statement, the return statement executes after the end statement executes, but finally does not change the return value, let's look at the code:

 Public Static int Test () {    int ret = 0;     Try {        return  ret;    } finally {        = 2;    }}

The return value of this function is 0, not 2, and the actual execution process is to execute the return ret in the try, before executing the finally statement and then returning the temporary variable by saving the returned value RET in a temporary variable. The changes to RET in finally are not returned.

What if there is a return statement in finally? Returns in the try and catch are lost, and the return value in finally is actually returned. Finally, return will not only overwrite the return value within the try and catch, but also obscure the exception within the try and catch, as if the exception had not occurred, such as:

 Public Static int Test () {    int ret = 0;     Try {        int a = 5/0;         return ret;    } finally {        return 2;    }}

In the above code, 5/0 will trigger ArithmeticException, but in finally there is a return statement, and this method returns 2 instead of passing the exception up.

Finally, not only the return statement will mask the exception, if the finally throws an exception, then the original exception will be masked, see the following code:

 Public Static void Test () {    try{        int a = 5/0;    } finally {        thrownew runtimeexception ("Hello");}    }

When the runtimeexception is thrown in finally, the original exception ArithmeticException is lost.

So, in general, to avoid confusion, you should avoid using a return statement or throwing an exception in finally, and if other code that you call might throw an exception, you should catch the exception and handle it.

Throws

In the exception mechanism, there is also a keyword throws, which is similar to throw , which declares an exception that a method might throw, as shown in the following syntax:

 Public void throws appexception, SQLException, numberformatexception {    //...}

Throws following the parentheses of the method, you can declare multiple exceptions, separated by commas. The implication of this statement is that I may throw these exceptions within this method, I have not processed them, at least not done, and the caller must handle them. This statement does not specify what exceptions will be thrown, and as a good practice, this information should be annotated in such a way that callers can better handle exceptions.

For runtimeexception (unchecked exception), it is not required to declare using throws, but for checked exception, it must be declared, in other words, if there is no declaration, it cannot be thrown.

For checked exception, it can not be thrown without declaration, but can be declared thrown but not actually thrown, do not throw declare it why? It is primarily used to declare in the parent class method that the parent class method may not be thrown, but may be thrown after the subclass overrides the method, and the subclass cannot throw checked exception that are not declared in the parent class method, so all possible exceptions are written to the parent class.

If one method invokes another that declares a method that throws checked exception, you must handle these checked exception, but you can handle it either as a catch or continue to use throws, as shown in the following code:

 Public void throws appexception {    try  {        test ();    }   Catch (SQLException e) {        e.printstacktrace ();    }}

For the sqlexception thrown by test, the catch is used here, and for appexception, it is added to the throws statement of its own method, which means that the current method is not processed, or it is handled by the upper layer.

Checked contrast unchecked Exception

Above, you can see the difference between runtimeexception (unchecked exception) and checked exception, checked exception must appear in the throws statement, the caller must handle, The Java compiler enforces this, and runtimeexception does not have this requirement.

Why do we have this distinction? Should we use checked or unchecked exception when we define our own anomalies? The industry has a wide range of views and debates on this issue, and there is no particular consensus on the conclusion.

A common argument is that runtimeexception (unchecked) represents a logic error in programming, and should be checked to avoid these errors when programming, such as null pointer exceptions, and if these exceptions occur, the program exits normally. Programmers should check the program code for bugs instead of trying to handle the exception. Checked exception indicates that the program itself is not a problem, but because of the exception caused by other unpredictable errors such as I/O, network, database, etc., the caller should handle it appropriately.

But in fact, programming errors should also be handled, especially, Java is widely used in server programs, not because of a logic error in the program to quit. So, at present, a more accepted view is that this distinction in Java is not very significant, can be used uniformly runtimeexception that is unchcked exception instead.

The basic reason for this view is that whether it is a checked or a unchecked exception, whether or not it appears in the throws declaration, we should handle it in the right place, not just to meet the compiler's requirements, to handle the exception blindly, Since all the exceptions are handled, the mandatory declaration and handling of checked exception is verbose, especially if the call hierarchy is deep.

In fact, the view itself is not too important, more important is consistency , a project, should be on how to use exceptions to agree, according to the agreed to use. The exceptions and class libraries already in Java are already there, and we still have to use them as they are required.

How to use exceptions

For exceptions, we introduced try/catch/finally, catch matching, re-throwing, throws, checked/unchecked exception, so how do we use exceptions?

Exceptions should and only be used for exception cases

The implication is that an exception cannot be used as a substitute for normal condition judgments . For example, when iterating over an array element, you should first check that the index is valid before processing, rather than waiting to throw an index exception and end the loop. For a reference variable, if its value is also likely to be null, then it should be checked for null and NOT NULL before calling.

On the other hand, when a real exception occurs, you should throw an exception instead of returning a special value, for example, we look at the substring method of string, which returns a substring with the following code:

 PublicString substring (intbeginindex) {    if(Beginindex < 0) {        Throw Newstringindexoutofboundsexception (Beginindex); }    intSublen = Value.length-Beginindex; if(Sublen < 0) {        Throw Newstringindexoutofboundsexception (Sublen); }    return(Beginindex = = 0)? This:NewString (value, Beginindex, Sublen);}

The code checks the validity of the beginindex and throws stringindexoutofboundsexception if it is not valid. One possible alternative to pure technology is to return a special value null without throwing an exception, but Beginindex is an exception, and the exception cannot pretend to be handled normally.

Target of exception handling

Exceptions can be divided into three sources: users, programmers, third parties. user refers to the user's input has a problem, the programmer refers to programming errors, third parties refer to other situations such as I/O errors, networks, databases, third-party services and so on. Each type of exception should be handled appropriately.

The target of processing can be divided into reports and recoveries. recovery refers to the automatic resolution of the problem through a program. The final object of the report may be the user, the program consumer, or the system operator or programmer. The purpose of the report is also to restore, but this recovery often requires human participation.

To the user, if the user input is not correct, may prompt the user specific where the input is wrong, if it is a programming error, may prompt the user system error, recommend contacting customer service, if it is a third-party connection problem, may prompt the user to retry later.

To the system operators or programmers, they generally do not care about user input errors, but focus on programming errors or third-party errors, for these errors, you need to report the full details, including the exception chain, exception stack, so as to locate and solve the problem as soon as possible.

For user input or programming errors, it is generally difficult to automatically resolve through the program, third-party errors may be, and even many times, the program should not assume that the third party is reliable, there should be a fault-tolerant mechanism. For example, if a third-party service is not connected (for example, texting), the possible fault-tolerant mechanism is to try another third party that provides the same functionality, or to retry for a period of time, and then report the error after multiple failures.

General logic for exception handling

If you know how to handle the exception, the processing, if it can be automatically resolved by the program, automatically resolve, if the exception can be resolved by themselves, there is no need to report up.

If you can't solve it completely, you should report it up. If you have additional information that you can provide to help you analyze and resolve the problem, you should provide that you can re-throw an exception with the original exception as cause.

There is always one layer of code that needs to be responsible for the exception, possibly the code that knows how to handle the exception, either in the face of the user's code or the main program. If the exception does not automatically resolve, for the user, should be based on the exception information users can understand and user-helpful information, on the operation and the programmer, you should output a detailed exception chain and exception stack to the log.

This logic is similar to the logic of dealing with the problem in the company, each level has its own problem to be solved, oneself can deal with their own processing, can not handle the report to the superior, the subordinate told him, and he knew, and told the superiors, in the end, the company boss must be responsible for all issues. Each level should neither conceal the problem nor evade responsibility.

Summary

The exception mechanism in Java is described in the previous section and this section. In the absence of an exception mechanism, the only exit mechanism is return, and the method of judging whether the exception is the return value.

Methods depending on whether the exception returns different return values, the caller is judged according to the different return values and handled accordingly. Each layer of the method needs to examine and process each different return value of the called method, and the normal logic and exception logic of the program are mixed together, and the code is often difficult to read and understand and maintain.

In addition, because the exception is a few cases, the programmer often lazy, assuming that the exception does not occur, and ignore the abnormal return value of the check, reducing the program's reliability.

In the abnormal mechanism, the normal logic of the program and the exception logic can be separated, the exception can be centralized processing, the exception can be automatically passed up, no longer require each layer of methods are processed, the exception can no longer be automatically ignored, thus, the code to deal with abnormal conditions can be greatly reduced, code readability, reliability, Maintainability can also be improved.

So far, the main concept of the Java language itself is about the same, and in the next few sections, we'll cover some of the common classes and their operations in Java, starting with the wrapper class.

----------------

To be continued, check out the latest articles, please pay attention to the public number "old Horse Programming" (Scan the QR code below), from the introduction to advanced, in layman's words, Lao Ma and you explore the nature of Java programming and computer technology. Write attentively, original articles, and keep all copyrights.

-----------

More Praise original Articles

Thinking Logic of computer programs (1)-Data and variables

Thinking Logic of computer programs (5)-Why do decimal calculations go wrong?

Computer Program Thinking Logic (6)-How to recover from garbled characters (top)?

Logic of the computer program (8)-the true meaning of char

Thinking Logic of computer program (12)-basic principle of function call

The thinking Logic of computer program (17)-The basic principle of inheriting implementation

Logic of the computer program (18)-Why inheritance is a double-edged sword.

The thinking Logic of computer program (19)-The nature of the interface

Thinking Logic of computer programs (20)-Why abstract classes?

Thinking Logic of computer programs (21)-The nature of inner classes

The thinking Logic of computer programs (23)-The nature of enumerations

Logic of the computer program (24)-Exceptions (UP)

Thinking Logic of computer programs (25)-Exceptions (bottom)