异常处理的策略。

[Keanu_Rocky]

1。按照《Thinking in Java》的说法（见其第十章，通过异常处理错误），异常处理的策略应该是通过异常对象的类型来区分不同的错误类型，在异常对象内不包含有意义的信息。如果这样做的话，当系统规模较大是，错误的类型也会很多，势必要定义庞大的异常继承体系。
2。另一种处理策略（我现在做的项目所使用的策略）是定义一个通用的Exception subclass，该异常的对象内包含一个错误代码，用这个错误代码来区分不同类型的错误。
在我看来，好像后者比前者更好。各位以为如何？各有什么优缺点？还有没有其他的策略？

[dongjb]

首选第一种
1。方案1相对2直接明了，不需要维护异常和异常代码的对照
2。不需要复杂的异常继承体系

[maowu]

第二种方案明显放弃oo的优点。更加难与维护。
另外，thinking in java的作者已经改变他的想法了，
他认为java的checked exception是一个失败的尝试。
他现在认为应该在整个项目中全部用runtimeException,
你可以上他的网站看看。
http://www.mindview.net/Etc/Discussions/CheckedExceptions

[baitianhai]

spring 正是你需要的

[yu_shi_bin]

关注一下

[passren]

學習

[Keanu_Rocky]

第二种方法真的比第一种方法更难以维护吗？第二种方法可以采用以下策略增强其可维护性：
1。错误代码可以划分位数，采用层次结构，同样会有清晰的结构。
2。错误代码和对应的错误信息可以存储在数据库内，不需要人工维护。（不要认为访问数据库会使程序变慢，因为一方面异常不会经常发生，另一方面我现在关心的是如何提高程序员的工作效率，而不是机器运行的效率）
在实际的系统中，我们到底应作何选择？仅仅因为某种方法更加符合OO的思想就偏爱它，是否不够理智？

[Keanu_Rocky]

to maowu:
你所链接的文章我看了，不过那也不是我要的答案，Bruce Eckel的新方法仍然是基于我所说的第一种方法的，仍然需要建立庞大的继承体系，不过他使用了RuntimeException的subclass来封装所有的自定义异常，给程序员更大的选择性，可以选择处理异常，也可以选择不处理异常，反而使得所有的异常都得到更恰当的处理。
我现在的问题是，到底需不需要建立庞大的异常继承体系，也许用一个包含有用信息的通用异常类更好？

[Keanu_Rocky]

spring我没用用过，有时间一定会学习的，谢谢hong

[maowu]

我仍然认为要维护异常和异常代码的对照是一个极为痛苦的事情.
也许你找到了一套把这些问题处理好的办法.