Share some suggestions on Java exception handling (Collection)

Java providesthrowing exceptions, catching exceptions and the use of finally statements to handle program exceptions. Let’s take a closer look at some suggestions about JavaException handling

Item 1: Use exceptions only for abnormal conditions

Recommendation: Exceptions should only be used for abnormal conditions , they should never be used for normal control flow.

Explain by comparing the two codes below.

Code 1

try { int i=0; while (true) { arr[i]=0; i++; } } catch (IndexOutOfBoundsException e) { }

Code 2

for (int i=0; i
      
Two copies The function of the code is to traverse the arr array and set the value of each element in the array to 0. Code 1 is terminated by an exception, which seems very difficult to understand. Code 2 is terminated by an array boundary. We should avoid using the method of code 1 for three main reasons:
      

       
The exception mechanism is originally designed to be used in abnormal situations, so few JVM implementations try to handle them performance optimization. Therefore, creating, throwing, and catching exceptions is expensive.
       
Putting code in a try-catch return prevents the JVM from implementing certain optimizations that it might otherwise perform.
       
The standard pattern of array traversal does not result in redundant checks, and some modern JVM implementations will optimize them away.
      
      
In fact, exception-based mode is much slower than standard mode. The test code is as follows:
      


      
public class Advice1 { private static int[] arr = new int[]{1,2,3,4,5}; private static int SIZE = 10000; public static void main(String[] args) { long s1 = System.currentTimeMillis(); for (int i=0; i

      
endByRange time:8ms endByException time:16ms
      
Result description: Speed of exception traversal Much slower than the normal wayTraversing the array!

      
Item 2: Use checked exceptions for recoverable conditions and runtime exceptions for program errors
      

       
Runtime Exception -- The RuntimeException class and its subclasses are called runtime exceptions.
       
Checked exceptions - the Exception class itself, and other subclasses of Exception subclasses except "runtime exceptions" are all checked exceptions.
      
      
The difference between them is:The Java compiler will check "checked exceptions", but will not check "runtime exceptions". That is to say, for checked exceptions, they must be declared to be thrown through throws or captured through try-catch, otherwise they cannot pass compilation. As for runtime exceptions, if it is neither thrown through the throws statement nor caught with a try-catch statement, the compiler will still pass. Of course, although the Java compiler does not check runtime exceptions, we can also explain the exception through throws or capture it through try-catch.

      
ArithmeticException (for example, the divisor is 0), IndexOutOfBoundsException (for example, the array is out of bounds), etc. are all runtime exceptions. For this kind of exception, we should avoid it by modifying the code. For checked exceptions, the program can be resumed through processing. For example, suppose a user's attempt to place a call on a payphone fails because he does not store a sufficient number of prefixes; a checked exception is thrown.

      
Item 3: Avoid unnecessary use of checked exceptions

      
"Checked exceptions" are A great feature of the Java language. Unlike return codes, "checked exceptions" force programmers to handle exception conditions, greatly improving the reliability of the program.

      
However, excessive use of checked exceptions will make the API very inconvenient to use. If a method throws one or more checked exceptions, the code that calls the method must handle these exceptions in one or more catch blocks, or it must throw these exceptions through the throws declaration. Whether it is handled through catch or thrown through the throws statement, it adds a non-negligible burden to the programmer.

      
Applicable to "checked exceptions" must meet two conditions at the same time: First,Even if the API is used correctly, it does not prevent the occurrence of exception conditions. Second,Once an exception occurs, programmers using the API can take useful actions tohandle the program.

      
Article 4: Try to use standard exceptions

      
Code reuse is worth promoting, this is a general rule Rules, exceptions are no exception. Reusing existing exceptions has several benefits:

      
First, it makes your API easier to learn and use because it is consistent with idioms that programmers are already familiar with.

      
Second, for programs that use these APIs, they are more readable because they are not filled with exceptions that are unfamiliar to programmers.

      
第三，异常类越少，意味着内存占用越小，并且转载这些类的时间开销也越小。

      
虽然它们是Java平台库迄今为止最常被重用的异常，但是，在许可的条件下，其它的异常也可以被重用。例如，如果你要实现诸如复数或者矩阵之类的算术对象，那么重用ArithmeticException和NumberFormatException将是非常合适的。如果一个异常满足你的需要，则不要犹豫，使用就可以，不过你一定要确保抛出异常的条件与该异常的文档中描述的条件一致。这种重用必须建立在语义的基础上，而不是名字的基础上！

      
最后，一定要清楚，选择重用哪一种异常并没有必须遵循的规则。例如，考虑纸牌对象的情形，假设有一个用于发牌操作的方法，它的参数(handSize)是发一手牌的纸牌张数。假设调用者在这个参数中传递的值大于整副牌的剩余张数。那么这种情形既可以被解释为IllegalArgumentException(handSize的值太大)，也可以被解释为IllegalStateException(相对客户的请求而言，纸牌对象的纸牌太少)。

      
第5条: 抛出的异常要适合于相应的抽象

      
如果一个方法抛出的异常与它执行的任务没有明显的关联关系，这种情形会让人不知所措。当一个方法传递一个由低层抽象抛出的异常时，往往会发生这种情况。这种情况发生时，不仅让人困惑，而且也"污染"了高层API。

      
为了避免这个问题，高层实现应该捕获低层的异常，同时抛出一个可以按照高层抽象进行介绍的异常。这种做法被称为"异常转译(exception translation)"。

      
例如，在Java的集合框架AbstractSequentialList的get()方法如下(基于JDK1.7.0_40)：
      


      
public E get(int index) { try { return listIterator(index).next(); } catch (NoSuchElementException exc) { throw new IndexOutOfBoundsException("Index: "+index); } }
      
listIterator(index)会返回ListIterator对象，调用该对象的next()方法可能会抛出NoSuchElementException异常。而在get()方法中，抛出NoSuchElementException异常会让人感到困惑。所以，get()对NoSuchElementException进行了捕获，并抛出了IndexOutOfBoundsException异常。即，相当于将NoSuchElementException转译成了IndexOutOfBoundsException异常。

      
第6条: 每个方法抛出的异常都要有文档

      
要单独的声明被检查的异常，并且利用Javadoc的@throws标记，准确地记录下每个异常被抛出的条件。

      
如果一个类中的许多方法处于同样的原因而抛出同一个异常，那么在该类的文档注释中对这个异常做文档，而不是为每个方法单独做文档，这是可以接受的。

      
第7条: 在细节消息中包含失败 -- 捕获消息

      
简而言之，当我们自定义异常或者抛出异常时，应该包含失败相关的信息。

      
当一个程序由于一个未被捕获的异常而失败的时候，系统会自动打印出该异常的栈轨迹。在栈轨迹中包含该异常的字符串表示。典型情况下它包含该异常类的类名，以及紧随其后的细节消息。

      
第8条: 努力使失败保持原子性

      
当一个对象抛出一个异常之后，我们总期望这个对象仍然保持在一种定义良好的可用状态之中。对于被检查的异常而言，这尤为重要，因为调用者通常期望从被检查的异常中恢复过来。

      
一般而言，一个失败的方法调用应该保持使对象保持在"它在被调用之前的状态"。具有这种属性的方法被称为具有"失败原子性(failure atomic)"。可以理解为，失败了还保持着原子性。对象保持"失败原子性"的方式有几种：

      
(01) 设计一个非可变对象。

      
(02) 对于在可变对象上执行操作的方法，获得"失败原子性"的最常见方法是，在执行操作之前检查参数的有效性。如下(Stack.java中的pop方法)：
      


      
public Object pop() { if (size==0) throw new EmptyStackException(); Object result = elements[--size]; elements[size] = null; return result; }
      
(03) 与上一种方法类似，可以对计算处理过程调整顺序，使得任何可能会失败的计算部分都发生在对象状态被修改之前。

      
(04) 编写一段恢复代码，由它来解释操作过程中发生的失败，以及使对象回滚到操作开始之前的状态上。

      
(05) 在对象的一份临时拷贝上执行操作，当操作完成之后再把临时拷贝中的结果复制给原来的对象。
虽然"保持对象的失败原子性"是期望目标，但它并不总是可以做得到。例如，如果多个线程企图在没有适当的同步机制的情况下，并发的访问一个对象，那么该对象就有可能被留在不一致的状态中。

      
即使在可以实现"失败原子性"的场合，它也不是总被期望的。对于某些操作，它会显著的增加开销或者复杂性。

      
总的规则是：作为方法规范的一部分，任何一个异常都不应该改变对象调用该方法之前的状态，如果这条规则被违反，则API文档中应该清楚的指明对象将会处于什么样的状态。

      
第9条: 不要忽略异常

      
当一个API的设计者声明一个方法会抛出某个异常的时候，他们正在试图说明某些事情。所以，请不要忽略它！忽略异常的代码如下：

      


      
try { ... } catch (SomeException e) { }
      
空的catch块会使异常达不到应有的目的，异常的目的是强迫你处理不正常的条件。忽略一个异常，就如同忽略一个火警信号一样 -- 若把火警信号器关闭了，那么当真正的火灾发生时，就没有人看到火警信号了。所以，至少catch块应该包含一条说明，用来解释为什么忽略这个异常是合适的。
      
The above is the detailed content of Share some suggestions on Java exception handling (Collection). For more information, please follow other related articles on the PHP Chinese website!