展开全部

最熟悉的陌生人：异常

异常的类e5a48de588b63231313335323631343130323136353331333361326365型Throwable

— Exception

—- RuntimeException

— Error

需要注意的是，RuntimeException及其子类不需要在方法签名中显示注明异常抛出。

例如：

void runtimeExceptionMethod1() {

throw new RuntimeException();

}

和：

void runtimeExceptionMethod2() throws RuntimeException {

throw new RuntimeException();

}

都可以，但是很多时候建议注明异常抛出。

异常的方法签名和子类

方法签名的异常定义等于或者是实际抛出异常的父类

void ioExceptionMethod1() throws IOException {

throw new IOException();

}

或者

void ioExceptionMethod2() throws IOException {

throw new FileNotFoundException();

}

都是可以的。

RuntimeException的特殊性

可以使用try-finally这种形式。

void runtimeExceptionMethod3() {

try {

runtimeExceptionMethod1();

} finally {

}

}

这个时候，不会处理异常，异常仍然会抛出给调用者。

异常处理分为两种方式：

1处理

2抛给调用者

最常见的形式：

try {

} catch(Exception e) {

}

如果有额外的硬件资源或者锁需要释放的时候，需要增加finally.

try {

} catch(Exception e) {

} finally() {

}

举几个例子：

第一个例子：文件流的使用和关闭：

File realFile = new File(dir, "laplace.demo");

FileOutputStream fos = null;

try {

fos = new FileOutputStream(realFile);

fos.write(data);

fos.flush();

} catch (Exception var9) {

var9.printStackTrace();

} finally {

Utilities.silentlyClose(fos);

}

第二个例子：锁的释放

Lock lock = null;

try{

lock = new ReentrantLock();

lock.lock();

// Some sentence may cause exception.

} catch (Exception e){

} finally {

if(lock != null){

lock.unlock();

}

}

处理的原则

在讲述了基本的原理后，讲解一下处理的原则。

调用者是否关心异常发生的后果

如果异常发生后，会要有不同的处理逻辑，那么被调用者应该将异常抛出。

作为sdk组件而言，本身无法知道纷繁复杂的需求，所以通常是需要将异常抛出，而不是自己处理。

对于业务层代码而言，更多时候需要考虑到借口的友善性，可能会做出异常的处理，而不是再向调用者抛出。

此外，还有一些Java规范基本的约定：

例如通常只建议处理Exception，而不建议处理Error。

但是在实际的产品过程中，只要不是完全不能运行的情况，我们希望给用户的感觉是，似乎发生了部分错误，但是整个程序还在运行，并没有奔溃。

所以，对于异常类型的实际处理，还取决于产品逻辑。