异常的类型通常足以正确处理它(例如,您尝试打开文件并获得FileNotFoundException
)。但是,在某些情况下,您可能会捕获同一类型的多个异常。例如,IllegalArgumentException
可能由多个参数引起。 IllegalArgumentException
不会向Throwable
界面添加任何其他方法(或公共字段)(根据在线javadoc),这意味着您可以依赖的唯一信息是嵌套异常(可能存在或可能不存在)和消息(供人类消费)。
我不喜欢扩展IllegalArgumentException
以向其添加结构化信息的想法,因为其他人必须学习新课程。而且我不喜欢乱扔乱画项目的想法非常具体的异常类。
使用消息字段也是一个坏主意,因为它不适用于编程访问。
我认为IllegalArgumentException
应该包含详细信息,例如有关的类函数和参数。一般而言,自定义异常应该提供额外的细节(除了它们的类型之外),以便进行更细粒度的异常处理。
通常认为设计异常类和处理相同类型的异常的最佳实践是什么?
答案 0 :(得分:5)
作为一般规则,我认为 理想的是每个“调用者可能合理想要采取的行动类型”有一类异常。当然,对于一个人自己的自定义异常,可能有一个布尔或枚举字段提供一些额外的消歧,而不是创建简单的子类。
在您的具体情况下,我不相信尝试处理异常是一个好主意。 RuntimeException
及其子类通常代表编码问题,IllegalArgumentException
也是如此。如果参数是非法的,则不应该首先传入。
如果您的情况是确定,如果参数有效(可能是用户输入,或者您可能不知道您正在调用该方法的特定对象)然后一个更好的方法是在传递参数之前有一些方法检查参数的有效性。而不是说“做这个”并抓住异常,问“我可以这样做吗?”在打电话之前。
答案 1 :(得分:1)
应设计异常类,以便在捕获时提供所需的所有内容。请注意,try/catch
语句实际上是一种类型切换形式,因此一般来说创建其他异常类更加清晰,而不是通过在{{1}内嵌套太多if
来混淆程序逻辑条款。
必须要说的是,如果你想以面向对象的方式组织你的错误处理代码,catch子句不是很方便,所以要记住不同的权衡。
请注意,标准异常类确实有关于导致异常的代码段的信息,即使我不建议您将错误处理逻辑基于它。
如果当前异常是针对另一个异常的catch子句抛出的,那么catch
方法应该可以使用此异常,而getCause()
应该可以访问当您的活动时激活的一组调用抛出异常。
除了调试目的之外,我不建议您使用此信息。
答案 2 :(得分:0)
确实,预定义的异常类非常通用。但是,如果您想了解有关例外的更多具体细节,那么您应该选择用户定义的例外。你应该用任何级别的细节创建自己的异常类!
这里是伪代码:
public class TooManyArguments extends exception{
public String toString(){
return ("..whatever information you want to give for this exception..")'
}
}
并且每当遇到异常情况时抛出此类的实例
throw new TooManyArguments();