Java理论与实践: 关于异常的争论 - 编程入门网
| printStackTrace(System.err);
}
public void printStackTrace(java.io.PrintStream s) {
synchronized(s) {
s.print(getClass().getName() + ": ");
s.print(stackTrace);
}
}
public void printStackTrace(java.io.PrintWriter s) {
synchronized(s) {
s.print(getClass().getName() + ": ");
s.print(stackTrace);
}
}
public void rethrow() { throw originalException; }
}
如果查看 Eckel 的 Web 站点上的讨论，您将会发现回应者是严重分裂的。 一些人认为他的提议是荒谬的；一些人认为这是一个重要的思想。（我的观点是 ，尽管恰当地使用异常确实是很难的，并且对异常用不好的例子大量存在，但是 大多数赞同他的人是因为错误的原因才这样做的，这与一个政客位于一个可以随 便获取巧克力的平台上参选将会获得十岁孩子的大量选票的情况具有相似之处。 ） Java理论与实践: 关于异常的争论(4)时间:2010-12-21 IBM Brian GoetzRod Johnson 是 J2EE Design and Development（请参阅 参考资料） 的作 者，这是我所读过的关于 Java 开发，J2EE 等方面的最好的书籍之一。他采取 一个不太激进的方法。他列举了异常的多个类别，并且为每个类别确定一个策略 。一些异常本质上是次要的返回代码（它通常指示违反业务规则），而一些异常 则是“发生某种可怕错误”（例如数据库连接失败）的变种。Johnson 提倡对于 第一种类别的异常（可选的返回代码）使用检查型异常，而对于后者使用运行时 异常。在“发生某种可怕错误”的类别中，其动机是简单地认识到没有调用者能 够有效地处理该异常，因此它也可能以各种方式沿着栈向上扩散而对于中间代码 的影响保持最小（并且最小化异常淹没的可能性）。 Johnson 还列举了一个中间情形，对此他提出一个问题，“只是少数调用者 希望处理问题吗？”对于这些情形，他也建议使用非检查型异常。作为该类别的 一个例子，他列举了 JDO 异常 —— 大多数情况下，JDO 异常表示的情况是调 用者不希望处理的，但是在某些情况下，捕获和处理特定类型的异常是有用的。 他建议在这里使用非检查型异常，而不是让其余的使用 JDO 的类通过捕获和重 新抛出这些异常的形式来弥补这个可能性。 使用非检查型异常 关于是否使用非检查型异常的决定是复杂的，并且很显然没有明显的答案。 Sun 的建议是对于任何情况使用它们，而 C# 方法（也就是 Eckel 和其他人所 赞同的）是对于任何情况都不使用它们。其他人说，“还存在一个中间情形。” 通过在 C++ 中使用异常，其中所有的异常都是非检查型的，我已经发现非检 查型异常的最大风险之一就是它并没有按照检查型异常采用的方式那样自我文档 化。除非 API 的创建者明确地文档化将要抛出的异常，否则调用者没有办法知 道在他们的代码中将要捕获的异常是什么。不幸的是，我的经验是大多数 C++ API 的文档化非常差，并且即使文档化很好的 API 也缺乏关于从一个给定方法 可能抛出的异常的足够信息。我看不出有任何理由可以说该问题对于 Java 类库 不是同样的常见，因为 Jav 类库严重依赖于非检查型异常。依赖于您自己的或 者您的合作伙伴的编程技巧是非常困难的；如果不得不依赖于某个人的文档化技 巧，那么对于他的代码您可能得使用调用栈中的十六个帧来作为您的主要的错误 处理机制，这将会是令人恐慌的。 文档化问题进一步强调为什么懒惰是导致选择使用非检查型异常的一个不好 的原因，因为对于文档化增加给包的负担，使用非检查型异常应该比使用检查型 异常甚至更高（当文档化您所抛出的非检查型异常比检查型异 |
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢! |
