java异常——分析堆栈跟踪元素+使用异常机制的技巧

【0】README

0.1） 本文描述+源代码均转自 core java volume 1，旨在理解 java异常——分析堆栈跟踪元素+使用异常机制的技巧 的相关知识；

【1】分析堆栈跟踪元素相关

1.1）堆栈跟踪： 它是一个方法调用过程的列表，它包含了程序执行过程中方法调用的特定位置；
1.2）调用Throwable 类的 printStackTrace 方法访问堆栈跟踪的文本描述信息；

Throwable t = new Throwable();
ByteArrayOutputStream out = new ByteArrayOutputStream();
t.printStackTrace(out);
String descriptoin = out.toString();

1.3）更灵活的方法是使用 getStackTrace 方法，它会得到 StackTraceElement对象的一个数组，可以在你的程序中分析这个对象数组：

Throwable t = new Throwable()；
StackTraceElement[] frames = t.getStackTTrace() ;
for(StackTraceElement frame : frames )analyze frame

1.4）StackTraceElement类：含有能够获得文件名和当前执行的代码行号的方法；同时，还有能够获得类名和方法名的方法；
1.5）看个荔枝（静态的Thread.getAllStackTrace）方法，它可以产生所有线程的堆栈跟踪，下面给出这种方式的具体步骤：

Map<Thread, StackTrace[]> map = Thread.getAllStackTraces();
for(Thread t : map.keySet)
{StackTraceElement[] frames = map.get(i);analyze frames;
}

API java.lang.Throwable 1.0
Throwable(Throwable cause)
Throwable(String msg, Throwable cause) ：给定的原因构造一个 Throwable 对象；
Throwable initCause(Throable cause)：将这个对象设置为原因。如果这个对象已经设置为原因，则抛出异常；返回this 引用；
Throwable getCause()：获得设置为这个对象的原因的异常对象。如果没有设置原因，则返回 null；
StackTraceElement[] getStackTrace() ：获得构造这个对象时调用堆栈的跟踪；
void addSuppressed(Throwable t) ：为这个异常增加一个抑制异常，这出现在带资源的try 语句中，其中t 是close方法抛出的一个异常；
API lang.Exception
Exception(Throwable cause)
Exception(String msg, Throwable cause)：用给定的原因构造一个异常对象；
API java.lang.RuntimeException
RuntimeException(Throwable cause)
RuntimeException(String msg, Throwable cause) ：用给定原因构造一个 RuntimeException 异常；
API java.lang.StackTraceELement
String getFileName()：返回这个元素运行时对应的源文件名，如果这个信息不存在，返回null；
int getLineNumber()：返回这个元素运行时对应的源文件行数。如果不存在，返回-1；
String getClassName()：返回这个元素运行时对应的类的全名；
String getMethodName()：返回这个元素运行时对应的方法名。构造器名是，静态初始化器名是，这里无法区分同名的重载方法；
boolean isNativeMethod():如果这个元素运行时在一个本地方法中，则返回true；
String toString()：如果存在的话，返回一个包含类名，方法名，文件名和行数的格式化字符串；

【2】使用异常机制的技巧

2.1）异常处理不能代替简单的测试：

如以下代码或者是： if(!s.empty()) s.pop();
或者是：
try
{s.pop();
}
catch(EmptyStackException e)
{}

我们发现， 调用 isEmpty()的运行时间为 646ms ，而捕获 EmptyStackException 的运行时间为 21739 ms, 所以，我们可以看出，与执行简单的测试相比，捕获异常所花费的时间大大超过了前者，
因此使用异常的规则是：只在异常情况下使用异常机制；

2.2）不要过分地细化异常

很多coder 吧每一条语句都分装在一个独立的 try 语句块中；因此，有必要将整个任务包装在一个try 语句块中，这样，当任何一个操作出现问题时，整个任务都可以取消了；

2.3）利用异常层次结构

2.3.1）不要只抛出RuntimeException异常，应该寻找更加适当的子类或创建自己的异常类；
2.3.2）不要只捕获Throwable 异常，否则，会使代码更难读和维护；
2.3.3）考虑已检查异常与未检查异常的区别。因为已检查异常本身就很庞大，不要为逻辑错误抛出这些异常；
2.3.4）将一种异常转换为另一种异常时不要犹豫。例如，在解析某个文件的一个整数时，捕获 NumberFormatException 异常，然后将它转换为 IOException 或 MySubSystemException的子类；

2.4）不要压制异常，在java中，往往强烈地倾向于关闭异常

如果编写了一个调用另一个方法的方法，该方法有可能100年才抛出一个异常，那么编译器会因为没有将这个异常列在throws 表中产生抱怨。而没有将这个异常列在其中的原因是编译器将会对所有调用这个方法的方法进行异常处理的考虑，因此，应该将这个异常关闭；

public Image loadImage(String s)
{try{code that threatens to throw checked exceptions}catch(Exception e){}// so there
}

现在，这段代码就可以通过编译了；

2.5）在检查错误时，苛刻要比放任好

如，当栈空时， Stack.pop（）是返回一个 null ，还是抛出一个异常？我们认为：在出错的地方抛出一个 EmptyStackException 异常要比在后面抛出一个 NullPointerException 要好；

2.6）不要羞于传递异常

如， FileInputStream 构造器或 readLIne方法，这些方法就会本能地捕获这些可能产生的异常，其实，传递异常要比捕获这些异常更好：

public void readStuff(String filename) throws IOException
{InputStream in = new FileInputStream(filename);......
}

让高层次的方法通知用户发生了错误，或者放弃不成功的命令更加适宜；