2

异常的类型通常足以正确处理它（例如，您尝试打开一个文件并获取一个FileNotFoundException）。但是，在某些情况下，您可能会捕获多个相同类型的异常。例如，一个IllegalArgumentException可能由多个参数引起的。IllegalArgumentException不会向接口添加任何其他方法（或公共字段） （根据Throwable在线javadoc），这意味着您可以依赖的唯一信息是嵌套异常（可能存在也可能不存在）和消息（供人食用）。

我不喜欢扩展IllegalArgumentException以向其中添加结构化信息的想法，因为其他人必须学习新课程。而且我不喜欢用非常具体的异常类乱扔项目的想法。使用消息字段也是一个坏主意，因为它不适合编程访问。

我认为IllegalArgumentException应该包括详细信息，例如有问题的类函数和参数。一般来说，自定义异常应该提供额外的细节（除了它们的类型之外），以便进行更细粒度的异常处理。

通常认为设计异常类和处理相同类型异常的最佳实践是什么？

4

3 回答 3

5

作为一般规则，我认为每个“调用者可能合理地想要采取的行动类型”都有一类例外是理想的。当然，对于自己的自定义异常，可以有一个布尔或枚举字段提供一些额外的歧义，而不是创建琐碎的子类。

在您的具体情况下，我不相信尝试处理异常是一个好主意。 RuntimeException及其子类通常代表编码问题，. 也是如此IllegalArgumentException。如果参数是非法的，则不应首先传入。

如果您不确定参数是否有效（可能是用户输入，或者您不知道要调用该方法的特定对象），那么更好的方法是在传递参数之前检查参数有效性的某种方法。与其说“这样做”并捕捉异常，不如问“我可以这样做吗？” 打电话之前。

于 2013-10-14T09:26:44.633 回答
1

应设计异常类，以便在捕获它们时提供所需的一切。请注意，语句实际上是类型切换的一种形式，因此通常创建额外的异常类而不是通过在子句中try/catch嵌套太多的来混淆程序逻辑更简洁。ifcatch

不得不说，如果你想以面向对象的方式组织你的错误处理代码，catch 子句不是很方便，所以要记住不同的权衡。

请注意，标准异常类确实具有有关导致异常的代码段的信息，即使我不建议您将其作为错误处理逻辑的基础。

如果当前异常是在针对不同异常的 catch 子句中引发的，则该方法应该可以使用该getCause()方法，而该方法getStackTrace()应该提供对引发异常时处于活动状态的调用堆栈的访问权限。

同样，我不建议您使用此信息，除非用于调试目的。

于 2013-10-14T10:21:30.320 回答
0

确实，预定义的异常类非常通用。但是，如果您想要有关异常的更具体的详细信息，那么您应该使用用户定义的异常。您应该创建自己的具有任何详细程度的异常类！

这是伪代码： 

public class TooManyArguments extends exception{
    public String toString(){
    return ("..whatever information you want to give for this exception..")'
    }

}

并且每当您遇到异常情况时，都会抛出此类的实例

throw new TooManyArguments();
于 2013-10-14T09:39:29.697 回答