我在某处（现在无法找到它）读取大的异常层次结构是浪费时间。这个陈述的理由在当时听起来很合理，而且这个想法还伴随着我。异常层次与错误枚举
在我自己的代码中，当我有一个代码库可以有一系列的错误条件时，我使用一个枚举成员的异常来区分它们。
如果出现这种情况，我需要赶上这些错误之一，我抓住它，检查枚举并重新抛出，如果它不是我所期望的。理想情况下，这应该是罕见的。
我正在处理异常，我有一个反思时刻，在那里我质疑了我的异常习惯。我很好奇别人做了什么，为什么？
层次结构或数据成员有一个例外。
顺便说一句，我假设你同意异常与错误代码的想法。我不希望打开那些蠕虫。
规则很简单：
我喜欢针对不同类别的错误（例如致命/非致命条件或应用程序的特定图层或模块）使用少量例外。然后，异常的抛出者应该提供代码以包含作为异常的有效载荷。应用程序的表示层可以查找与代码相对应的本地化人类可读的错误消息。
总之，异常类型对开发人员非常有用，对应于错误代码的消息对用户很有用。
我认为仅具有一个与嵌入式枚举异常类型是次优的：
要回答你的问题，我使用了异常的层次结构。它比它深广得多。
根据我的经验，太多的异常类只会变得令人困惑，特别是它们只能用于一个非常特定类型的问题。我看到一个系统，每个错误条件都有自己的异常，但只有超级类在catch块中被检查。这些子类完全浪费时间。
另一方面，不得不检查枚举并重新抛出异常使得代码不那么直观，因为你不能识别catch之后直接抛出的异常。也许只是一个小缺点，但如果经常使用它可能会影响可读性。在需要非常快速的代码中使用时，它也可能会带来性能问题。
我不会使用枚举解决方案，但有一些异常类型具有足够广谱的用途。像DatabaseException一样，而不是像TableNotFoundException，ColumnNotFoundexception等几个异常。根据我的经验，这对大多数开发人员来说效果最好。您可以随时添加一个带有一些显示给用户的错误代码的字段，以便于用户与支持之间的沟通。
你不要有一个例外类型和枚举亚型代替他们解决太多的异常类的问题。事实上，你只会变得更糟！
例如：假设您有异常类型Ex1..Ex99，例如， E14..E18是E1等的孩子，您现在决定用一个例外Ex和子类型ST1..ST99替换它们。你解决了什么？没有什么 - 人们仍然需要处理所有可能性。你做得更糟？您不能忽视ST14-ST18并将它们视为ST1的发生。你现在必须处理所有99种可能性，因为你枚举子类型没有自然的，灵活的层次结构。
我认为你是两个世界中最糟糕的。大的异常层次结构是无用的，因为客户端已知是懒惰的，并且最终只会检查顶层节点（可能只针对层次结构根节点）。你的枚举系统不能解决这个问题，并且会导致一个更麻烦的异常捕获系统。
如果你真的知道需要很多不同的异常和捕手会真正想要的不同的异常（知道，不是隐约觉得），与大层次继续前进，忘记了枚举。否则，坚持小的异常层次结构，只提供捕捉器真正感兴趣的异常类。
不要将错误与异常混淆。
发生错误，尽可能地解决问题。
例外情况非常罕见，如果没有更多上下文信息通常不可解决。
如果出现问题，可以修正本地，那么你可能要使用错误代码和处理它那里，然后。
异常应该被用来调用堆栈传播问题最多的是有足够的信息来解决问题的上下文。
话说：枚举没有去，因为他们绕过整个try抓机制，编译器会自动为你生成的方式。拇指
你不应该教条这一点。使用任何最适合解决问题的手段。我对这个经验法则如下：
@Andrew：关于“致命/非致命”的例外分类。这种分类应该在发现异常时确定，而不是抛出！因此它不能与异常类型相关。 – 2009-01-13 08:31:48