"Effective Java"--exception

Use exceptions only for exception cases

Exception design is intended to be used for the abnormal situation of the program, do not use exceptions to control program execution process

Use a inspected exception for recoverable cases, use a non-inspected exception for programming errors

Java has designed three types of structures that can be thrown

• Checked exception
• Runtim exception
• Error

Error generally, the Convention is commonly known as the use of virtual machines, indicating insufficient resources and other errors

Use a inspected exception for recoverable cases, use a non-inspected exception for programming errors

Avoid unnecessary use of checked exception

Using checked exception can be a huge burden to client programmers, and only if you meet the following two conditions, you should use checked exception

• This can happen even if the API is called correctly
• For exceptions to occur, programmers can take useful actions immediately

Otherwise, you should use runtime exception

Preferential use of standard exceptions

Reusing existing exceptions, there are three benefits

• Make your API easy to learn and use
• Readability is better for programs that use the API
• The fewer exception classes, the less overhead you can load

Common exceptions include the following

• IllegalArgumentException
• IllegalStateException
• NullPointerException
• Indexoutofboundexception
• Concurrentmodificationexception
• Unsupportedoperationexception

Throws an exception corresponding to the abstract

When the method is going to pass the exception thrown by the underlying implementation, the exception should be interpreted so that the underlying implementation is not contaminated with the upper API
For example

catch(IOException e){    thrownew ServiceException(e);}

There are usually two kinds of translation, one is the direct anomaly translation, and the other is the translation of the anomaly chain.
The above example is the translation of the exception chain, the caller can get a more basic exception through the exception, easy to troubleshoot problems, direct translation is not to pass the chain of exceptions, such as

catch(IOException e){    thrownew ServiceException("io exception");}

The above is only for certain to pass the underlying exception case of the processing method, for the underlying method, the preferred solution is to deal with the underlying exception, do not pass the impact of the exception to the upper layer, there are two ways to achieve

• Check the parameters to avoid calling the underlying method to find the exception
• To bypass the anomaly, record the exception and not propagate it.

Each method throws an exception that must have a document

Document descriptions for both checked exception and unchecked exception, but do not mark unchecked exception in method declarations

Include information in the detail message that could capture the failure

To record the various reasons for this exception, it is best to make the exception itself record the cause of the problem, for example, in the constructor of the exception contains some special fields, as in Indexoutofboundsexception can have the following construction method

publicIndexOutOfBoundsException(intintint index){    ...

Try to keep the failure atomic

A failed method call should keep the object in the state it was before it was called, and there are several ways to do so

• Using Immutable objects
• Check parameter validity before changing state, throw exception early
• Put the potentially failed action before the change state, so that the failure can end prematurely without leaving the object in an inconsistent state
• Write recovery code (infrequently used), typically for data that has persisted
• To make an operation perform on a temporary copy

Sometimes, it is not always possible to achieve the atomicity of failure, such as the state of a two thread unsafe concurrent modification object

Specification, any call failure should be the corresponding state in the previous state, how inconsistent, should be described in the document

Do not ignore exceptions

For exceptions, do not ignore exceptions at other times except when InputStream is turned off
The exception

• Either handle
• or spread it out.

This recommendation is used for checked and unchecked exceptions

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

"Effective Java"--exception