异常处理的策略。

Keanu_Rocky 2004-06-23 04:09:47
加精
1。按照《Thinking in Java》的说法(见其第十章,通过异常处理错误),异常处理的策略应该是通过异常对象的类型来区分不同的错误类型,在异常对象内不包含有意义的信息。如果这样做的话,当系统规模较大是,错误的类型也会很多,势必要定义庞大的异常继承体系。
2。另一种处理策略(我现在做的项目所使用的策略)是定义一个通用的Exception subclass,该异常的对象内包含一个错误代码,用这个错误代码来区分不同类型的错误。
在我看来,好像后者比前者更好。各位以为如何?各有什么优缺点?还有没有其他的策略?
...全文
173 9 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
9 条回复
切换为时间正序
请发表友善的回复…
发表回复
maowu 2004-06-24
  • 打赏
  • 举报
回复
我仍然认为要维护异常和异常代码的对照是一个极为痛苦的事情.
也许你找到了一套把这些问题处理好的办法.
Keanu_Rocky 2004-06-24
  • 打赏
  • 举报
回复
spring我没用用过,有时间一定会学习的,谢谢hong
Keanu_Rocky 2004-06-24
  • 打赏
  • 举报
回复
to maowu:
你所链接的文章我看了,不过那也不是我要的答案,Bruce Eckel的新方法仍然是基于我所说的第一种方法的,仍然需要建立庞大的继承体系,不过他使用了RuntimeException的subclass来封装所有的自定义异常,给程序员更大的选择性,可以选择处理异常,也可以选择不处理异常,反而使得所有的异常都得到更恰当的处理。
我现在的问题是,到底需不需要建立庞大的异常继承体系,也许用一个包含有用信息的通用异常类更好?
Keanu_Rocky 2004-06-24
  • 打赏
  • 举报
回复
第二种方法真的比第一种方法更难以维护吗?第二种方法可以采用以下策略增强其可维护性:
1。错误代码可以划分位数,采用层次结构,同样会有清晰的结构。
2。错误代码和对应的错误信息可以存储在数据库内,不需要人工维护。(不要认为访问数据库会使程序变慢,因为一方面异常不会经常发生,另一方面我现在关心的是如何提高程序员的工作效率,而不是机器运行的效率)
在实际的系统中,我们到底应作何选择?仅仅因为某种方法更加符合OO的思想就偏爱它,是否不够理智?
passren 2004-06-23
  • 打赏
  • 举报
回复
學習
yu_shi_bin 2004-06-23
  • 打赏
  • 举报
回复
关注一下
baitianhai 2004-06-23
  • 打赏
  • 举报
回复
spring 正是你需要的
maowu 2004-06-23
  • 打赏
  • 举报
回复
第二种方案明显放弃oo的优点。更加难与维护。
另外,thinking in java的作者已经改变他的想法了,
他认为java的checked exception是一个失败的尝试。
他现在认为应该在整个项目中全部用runtimeException,
你可以上他的网站看看。
http://www.mindview.net/Etc/Discussions/CheckedExceptions
dongjb 2004-06-23
  • 打赏
  • 举报
回复
首选第一种
1。方案1相对2直接明了,不需要维护异常和异常代码的对照
2。不需要复杂的异常继承体系

67,550

社区成员

发帖
与我相关
我的任务
社区描述
J2EE只是Java企业应用。我们需要一个跨J2SE/WEB/EJB的微容器,保护我们的业务核心组件(中间件),以延续它的生命力,而不是依赖J2SE/J2EE版本。
社区管理员
  • Java EE
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧