14

我正在为Exceptions我目前正在从事的项目实施我自己的一套。该项目依赖于一个带有基本框架异常的核心框架MyFrameworkException（我也在编写这个框架）。

对于任何给定的项目，我想抛出几种不同类型的Exceptions，我无法决定是使用多个子类还是使用具有某种形式的单个子类Enum作为构造函数参数。

在这两种情况下，我都有：

public class MyFrameworkException   extends Exception              { /*...*/ }

选项1：

public class MyProjectBaseException extends MyFrameworkException   { /*...*/ }
public class SpecificExceptionType1 extends MyProjectBaseException { /*...*/ }
public class SpecificExceptionType1 extends MyProjectBaseException { /*...*/ }
public class SpecificExceptionType1 extends MyProjectBaseException { /*...*/ }

然后，在整个项目中，我会针对发生的任何问题抛出特定异常。

选项 2：

public class MyProjectException extends MyFrameworkException {
  public static enum Type {
    SpecificType1, SpecificType2, SpecificType3
  }
  public MyProjectException( Type type ) { /*...*/ }
}

在这里，对于发生的任何问题，我总是会抛出MyProjectException特定的枚举类型。我会提供一些机制，以便可以MyProjectException基于枚举类型对任何对象执行 switch 语句。

在项目中处理异常的最佳方式是什么，尤其是那些共享公共基础设施的项目？以上两个选项是好的解决方案吗？为什么或者为什么不？还有什么更好的解决方案？

4

3 回答 3

6

选项 2（常见异常 + 枚举）的主要缺点是您失去了检查异常的一些实用性。一个方法几乎必须简单地说“与框架相关的东西可能会出错”：

public void foo()
throws MyFrameworkException

...而不是“x 或 y 可能出错”：

public void foo()
throws SomethingWentWrongException, SomethingElseWentWrongException

这意味着一个可能需要处理一个框架异常的函数必须准备好处理其中的任何一个，而如果你是特定的，一个函数只需要准备好处理它调用的框架方法抛出的异常。

所以对我来说，像选项 1 这样的层次结构（如果结构表明自己，它不需要那么平坦）是要走的路。也就是说，有些人根本不喜欢检查的异常，对他们来说，我怀疑以上不是一个令人信服的论点。:-)

编辑并接受 duffymo 的观点：我假设您在谈论您确实必须创建的异常。绝对在任何有意义的地方抛出标准异常（几乎无处不在）。MyFrameworkIllegalArgumentException例如，不要创建自己的，只需使用IllegalArgumentException（或其各种子类）。

于 2010-10-14T15:23:01.873 回答
3

我会选择使用描述性类名扩展 java.lang.RuntimeException 的异常。

如果您有太多特定于业务的例外情况，以至于这变得令人压抑，这意味着您可能做错了。

请参阅 Joshua Bloch 关于支持标准异常的建议。

于 2010-10-14T15:26:52.753 回答
1

MyFrameworkException只要您不提供所有项目共有的任何功能，我就不会从 generic 继承。否则，总是扩展异常。

通常你应该在域/层边界抛出有意义的异常。因此，关于您的问题，您应该选择选项 1，同时牢记上述要点。选项 2 会增加代码复杂性，因为您将始终需要检查异常类型以确定出了什么问题。让异常类自己说话。

于 2010-10-14T15:29:55.227 回答