无论你是使用何种编程语言，在日常的开发过程中，都会不可避免的要处理异常。今天本文将尝试讲解一些JVM如何处理异常问题，希望能够讲清楚这个内部的机制，如果对大家有所启发和帮助，则甚好。

当异常不仅仅是异常

我们在标题中提到了异常，然而这里指的异常并不是单纯的Exception，而是更为宽泛的Throwable。只是我们工作中习以为常的将它们（错误地）这样称谓。

关于Exception和Throwable的关系简单描述一下

• Exception属于Throwable的子类，Throwable的另一个重要的子类是Error
• throw可以抛出的都是Throwable和其子类，catch可捕获的也是Throwable和其子类。

在Java中，当我们定义一个类的时候，总会出现一些变量是必须要填写的，而另一些是可选的。比如像下面这样，我们定一个Person类，其中name是必须填写的，而性别sex和isChinese可选，如果不填写就直接使用默认值。

在Kotlin中，定义方法很有趣，不仅仅因为方法的关键字是fun(function前几个字符)，还是因为你会惊奇的发现，它允许我们在方法中定义方法。如下

1
2
3
4
5
6
7
8

fun methodA() {
   fun methodB() {

   }
   methodB() //valid
}

//methodB() invalid

在Java或者是Android编程中，我们一般都会使用到Map，比如HashMap这样的具体实现。更高级一点，我们可能会使用WeakHashMap。

WeakHashMap其实和HashMap大多数行为是一样的，只是WeakHashMap不会阻止GC回收key对象（不是value），那么WeakHashMap是怎么做到的呢，这就是我们研究的主要问题。

我们在编程中，无时无刻地都在于方法打交道，而在方法中，我们很难不使用局部变量，比如我们有下面的这样一段很简单的代码

1
2
3
4

public void dump() {
    String localName;
    System.out.println("dump localName=" + localName);
}

没有代码，就没有bug。程序员在编码时，总会比不避免的出现bug。倒不是因为我们热爱制造bug，创造机会和测试妹子频繁沟通。而是现实情况很复杂，存在着很多不确定性。尤其是那些崩溃从stacktrace上来看，完全想象不到和项目代码之间的直接联系。

用了一年宽带马上就要到期了，去联通营业厅咨询了一下，发现联通已经悄悄的把我的100M免费升级成了300M(做好事为什么不告诉我一声)。心中划过一丝窃喜，但是随后脑海中抛出了一个疑问，都升到了300M了，怎么丝毫没有感觉到速度提升呢？

我们在编程中的函数或者是方法，大多数都是有参数的。参数对于方法来说是很重要的输入数据，传入的参数值的合法性影响着方法的稳定性，严重时甚至可能导致崩溃问题的出现。

正所谓，要想没有bug，就一行代码也不写。App到了用户的手里，肯定是崩溃越少越好。Android中的崩溃处理和iOS不太一样，iOS崩溃通常是闪退，而安卓会出现如下的蹩脚的对话框

当你的用户看到类似这样的崩溃对话框时，心中得到“这届程序员不行啊”的感慨也不足为奇。