展开全部
最熟悉的陌生人：异常
异常的类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。
但是在实际的产品过程中，只要不是完全不能运行的情况，我们希望给用户的感觉是，似乎发生了部分错误，但是整个程序还在运行，并没有奔溃。
所以，对于异常类型的实际处理，还取决于产品逻辑。
