网站中异常设计思考

这个在本质上是没有什么区别的，用结果码，一样可以放在runtimeException里面。
如果只考虑用异常类型来区分异常的话，一样没有可能有办法得到各种异常的特定用户提示信息。
这里的焦点是如果得到特定用户提示信息，并且在底层异常有变化的时候，可以很好的对其应变。

特定信息......你用异常作常用判断么?
那是鲁棒性差的表现.

使用异常参与业务逻辑很多年前就开始被讨论。Robbin的观点是将异常参与到逻辑中去，作为一个异常事件流。起初我对这种做法是将信将疑的，不过通过几年的摸索，发现这才是一个最佳实践。

异常码决不是上个世纪的东西。台湾人常用异常码，欧美的项目中很难看到。不过最近在接触IBM的产品的时候，又一次看到了异常码。我后来仔细想了一下，异常码的使用实际上是一个产品化流程过程中的一个经历阶段。异常码实际上定义的是一类异常而非一个异常，这种情况下，异常的组织结构被淡化。所有的异常都来自RuntimeException，用异常码来区分异常的发生。

异常码的另外一个好处在于异常码在大型产品中可以被定义为一部数据字典，这个在IBM的产品中非常常见。同时，异常码还可以用于处理国际化等。在大型商业应用和产品级别的应用上，我越来越看得见异常码的光明前景。

问题是读不懂....
见过些银行项目

数据字典作成excl后有时会超过2W行上限.

而且现在ide还不支持对这种码的注释弹出.
无奈作出众多的异常类型....
放在不同的包下面
正在考虑作一个异常的工厂那样子方法上的注释就可以弹出来了.

其实在Try-Catch里面就是一种判断，不过可以利用多态性避免If else（实质还是逻辑判断）。

上限问题好解决，也不一定要IDE支持，关键看规约就行了。
不过，异常太多了理解和维护起来岂不是更麻烦？

PS:这么投隐藏的人，是不是真的都明白？觉得简单就不要看，别手贱！

异常的确是可以参与到业务中的，很多时候，一个FileNotFoundException和ZipException还是要区别对待的。异常参与业务，取决于我们怎么定义业务。

确实，你举的例子就是其中一种，这两类异常并没有层次关系，平行却有关联（同宗），都是继承于IOException。

不用读懂，只要有document可以reference就成。数据字典的大小不是问题，只要可查。

这东西的缺点我说了，是忽略异常的组织结构，其实2者是需要结合使用的。比如说，Spring的异常体系中，DataAccessException就可以作为一个比较大的根Exception来编写异常码，异常码可以规范到字符串的起始值或者代码数值的有效位数。在这种情况下，无论是数据字典的查阅还是程序员在写程序的时候，都不会遇到很大的问题。

其实归根结底是对业务的归类，我们讨论的前提条件是说BusinessException是我们需要处理的Checked Exception。所以作为构架师来说，设计合理的Exception层次结构并规范化，将是一个重要的任务。

这两个Exception都不是RuntimeException，所以除非你需要让他参与到业务流程中来，将其转化为BusinessException，否则就应该抛出去或者处理掉。