Atitit 异常机制与异常处理的原理与概论
1.1. Atitit.异常机制的设计原理.docx
JVM看Exception本质.java的ex设计throry
1.2. 终止模式 vs 恢复模式(asp
Java对于异常的处理采取的是终止模式，一旦发生问题，程序将不能继续执行，与之对应的是恢复模式，就是当异常抛出时，程序能够继续执行，而不是终止。在Java中如果我们要使用恢复模式，就需要将try块放在while循环中，直到满意，但这明显是不靠谱的，也是我们不提倡的。所以当当前方法终止时，我们只能在异常处理块中使程序向不同的方向继续执行，而具体向什么方向，取决于具体的实现
1.3. 处理反射方法的异常
public static void throwExV3(Throwable e,String msg) {
if(e instanceof InvocationTargetException )
{
e=e.getCause();
}
if( e instanceof RuntimeException)
{
Throwable e3=e.getCause();
RuntimeException runtimeException = new RuntimeException(msg,e3);
throw runtimeException;
// throw (RuntimeException)e;
}
else
throw new RuntimeException(msg,e);
}
1.4. 重新抛出异常和异常链
有时我们在捕获到异常后，可能在捕获的地方不适合处理该异常，我们需要将它重新抛出：
catch(Exception e){
throw e;
}
这样有一个好处，我们可以将异常交给上一级环境处理，但是这样就会存在一个问题，抛出的的异常携带的信息，也就是printStackTrace()方法显示的是原来异常抛出点的调用栈信息，而非重新抛出点的信息，这样重新抛出点的调用信息就被掩盖了。如果想更新重新抛出点信息到这个异常调用栈中，就可以使用fillInStackTrace()方法：
catch(Exception e){
throw e.fillInStackTrace();
}
那么当前调用栈的信息就更新到了这个异常对象中了，还有一种情况，也会存在类似的丢失现象：
catch(Exception e){
throw new Exception();
}
1.5. Finally 异常丢失的处理
我们把最外一层try看着是上一级程序的处理，在这个try里面发生了两次异常，但是我们只能获得从finally中抛出的异常信息，而在f()方法中的异常信息丢失，这种情况我们称上一个异常被抑制了。这在JDK1.7之前同样需要我们自己编码去解决这个问题，在JDK1.7之后，新加入了两个方法帮助我们能够很好的去解决这个问题了，那就是addSuppressed(Throwable exception)和getSuppressed()，对于上述问题的解决：
public static void main(String[] args) { try { Test test = new Test(); Exception exception = null; try { test.f(); } catch (VeryImportantException e) { exception = e; } finally { try { test.dispose(); } catch (OtherException e) { if (exception != null) { exception.addSuppressed(e); } else { exception = e; } } if (exception != null) { throw exception; } } } catch (Exception e) { System.out.println(e); for (Throwable throwable : e.getSuppressed()) { System.out.println(throwable); } } }
Java 异常详解 - weisg81的专栏 - 博客频道 - CSDN.NET.html
作者:: 绰号:老哇的爪子 （ 全名：：Attilax Akbar Al Rapanui 阿提拉克斯 阿克巴 阿尔 拉帕努伊 ）
汉字名：艾提拉（艾龙）， EMAIL:1466519819@qq.com
转载请注明来源： http://www.cnblogs.com/attilax/
Atiend