Valid Java notes (11)

List of related Reading Notes

No. 42 try to use standard exceptions

The most common reuse exception in the Java platform library so far is as follows:

The illegalargumentexception parameter value is not suitable.

Illegalstateexception is not suitable for this method call (for example, Initialization is inappropriate)

The value of nullpointerexception is null when null is disabled.

Indexoutofboundsexception subscript out of bounds

Concurrentmodificationexception when concurrent modification is prohibited, concurrent modification is detected on the object.

The unsupportedoperationexception object does not support the client request method.

Other exceptions can also be used, as long as the conditions for throwing exceptions are consistent with the requirements in the documentation.

No. 43 the exception thrown should be suitable for the corresponding Abstraction

High-Level Implementation should capture low-level exceptions and throw an exception that can be interpreted according to high-level abstraction. This practice is called exception translation ). Example:
// Exception translation! <Br/> try {<br/> // use lowlevel upload action to do our bidding <br/>... <br/>} catch (lowerlevelexception e) {<br/> throw new higherlevelexception (...); <br/>}

Low-level exceptions are saved by High-Level exceptions, and high-level exceptions provide a public access method to obtain low-level exceptions. This is called exception chaining ).
// Exception chaining. <br/> try {<br/> // use lower-level lower action to do our bindding <br/>... <br/>} catch (lowerlevelexception e) {<br/> throw new higherlevelexception (E); <br/>}

The implementation of exception chain is very simple. In versions 1.4 and later, throwable can be used for support.
// Exception chaining in release 1.4 or later <br/> higherlevelexception (throwable t) {<br/> super (t); <br/>}

Handle exceptions from lower layers,

The best practice is to ensure that the lower-layer methods are successfully executed through some checks and other means before calling them;

The second approach is to let the top management handle these exceptions and isolate the callers of the top method from the lower-layer problems;

The general practice is to use abnormal translation;

If the exception of the lower-layer method is also suitable for the upper-layer method, it is transferred from the lower-Layer Method to the upper-layer method.

No. 44 documentation is required for exceptions thrown by each method

It is always necessary to declare the checked exception separately and use the @ throws mark of jacadoc to accurately record the thrown conditions of each exception.

If you use the @ throws tag of javadoc to accumulate each unchecked exception that may be thrown by the next method, do not use the throws keyword to include the unchecked exception in the method declaration.

If many methods in a class throw the same exception for the same reason, document the exception in the document comment of the class instead of writing a document for each method.

No. 45 contain failure-capture information in the detail message

To capture failures, the exception information should contain as many meaningful parameters and domain values as possible. For example, indexoutofboundsexception should include the upper bound, lower bound, and actual subscript.

No. 46 keep failure atomic

An failed method call should keep the object in the State before it is called. The method is as follows:

① Use an immutable object;

② For operations on mutable objects, the parameter validity should be checked before execution;

③ Write a recovery code. If the execution fails, roll back to the status before the operation starts (not commonly used );

④ Perform an operation on a temporary copy of an object. After the operation is completed, copy the result in the temporary copy to the original object, such as collections. before executing sorting, sort first dumps its input to an array, which reduces the overhead of the inner loop and ensures that when sorting fails, the input list is unchanged.

No. 47 do not ignore exceptions

Unless you have special requirements (such as playing multiple frames in an animation), do not eat exceptions. At least a description is included in the catch block to explain why the exception is ignored. Simply spreading an unchecked exception to the outside world will at least cause the program to fail quickly, thus retaining information that helps debug the failure condition, this is better than program failure at an unpredictable moment after an exception is ignored.