今天的问题是关于异常，自然，今天的主角是异常之神。
我
问：大神，异常到底是个什么东西哩？什么情况下我们需要抛出异常呢
？
果然是异常之神，很异常，反问：如果老婆叫你去超市买虾，虾刚好卖光了，你
会怎么办？
我想都没想，说：给老婆打电话哈！
神仙说：这就是异常！
我说：不能完成买虾这个任务？
神仙说：不在你控制范围内的因素所造成的问题、没有预料到的情况就叫异常。
在上面这个例子里，由于你没法控制超市是否还有虾，所以当你面临这个问题而又无法自己解决时就会抛出这个异常。
我说：哦，异常有两个特点，
一个是造成不能正常执行任务的因素不
在我的控制范围，二是我自己没有足够的信息进行处理，只能抛出。
我
问：我知道JAVA里异常有checked和runtime之分，用哪个好呢？
神仙说：继续前面的问题，你和老婆打了电话，结果发现是女儿要吃虾，这时会
怎么办呢？
我说：老婆会让我等等，然后去问我女儿，然后再回答我，女儿说了，可以吃
鱼。
神仙说：实际处理这个问题的是你女儿？
我说：是的。
神仙说：那为什么你不直接让你女儿接电话哩？
我说：因为女儿管她妈妈，她妈妈管我。
神仙说：如果是checked异常，那么尽管妈妈不能处理这个问题，她还是
需要处理；如果是runtime，那么妈妈就不用操心啦。
我说：我明白了，checked异常强制我们在发生异常的地方进行处理，哪
怕实际我并不能处理，只会产生一坨一坨的try catch，runtime能够让我们在能够处理异常的地方才捕获这个异常。
神仙说：异常处理有一项很重要的目标，就是将处理异常的代码从异常发生的地
方移开。这样就能在一个地方集中精力去解决你想解决的问题，然后再到另一地方去处理这些异常问题。程序的主线就不会被异常处理这类枝节问题给搞得支离破
碎，程序也更易于理解和维护。
我说，所以
都用runtime异常，第三方的
checked异常如果不能立即处理，那么也应该转为runtime。
神仙说，异常处理的一个重要准则是：
如果你不知道该如何处理这个异常，那
么你就别去捕捉它。
我
说，太好了，checked异常必须处理，runtime异常不用处理！
神仙说，你会直接在用户界面打印出一坨坨黑白相间的美妙异常栈？
我说，当然不会，我会统一跳转到一个出错页面。
神仙说，难道这不是对异常的处理吗？
我说，恩，也是。
神仙说，
所有异常必须处理
！在程序里可以抛异常，但是决不能把异常抛给最终用户。BUG在程序员手里还不是BUG，但是一旦交付，那么
就是BUG。
我
问：出现异常的地方我直接new RuntimeException()可以吗
？反正最后是告诉老婆买不成虾。
神仙说，如果你女儿问为什么没买到虾怎么办？
我说，我会告诉她虾卖完了。
神仙说，信息在哪儿呢？
我说，我明白了，扔出异常一定要加上异常信息。
神仙说，非常重要！对于最终用户可能仅仅是个出错页面，但是对于需要解决这
个问题的程序员来说，异常信息就非常重要了。
我说，
所以如果是自定义异常，那么一定要加异常信息；如果是checked异常转runtime则一
定要保存原有的异常，形成异常栈。
我
问：好吧，我看到很多程序都自定义异常。
神仙说，如果是通货膨胀钱没带够而买不了虾怎么办？
我说，我会回家取钱。
神仙说，那么如果是虾没了呢？
我说，那买个鬼，卖鱼罗。
神仙说，所以需要自定义异常，这样可以产生不同的异常处理策略。
我说，
如果需要对不同的异常进行不同的处理，那么就需要自定义异常。
神仙说，
自定义异常需要有自己的继承体系
，这样当我不想单个处理时，可以对一种类型的异常采用统一的一种处理，例如spring的
DataAccessException。
我暗喜：正在写工作流异常模式哩，何不一起问一下？哈哈。
神仙说：未完待续，敬请期待工作流异常的问与答。