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);
    ......
}

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