何时使用自定义例外与现有例外与一般例外

Question

我正在试图找出正在编写的库的正确形式。我需要处理的一个例子是将用户登录到工作站。他们通过扫描徽章来做到这一点。可能出错的可能包括：

• 他们的徽章已停用
• 他们无权在本站工作
• 系统中不存在扫描的徽章
• 他们已经登录到其他地方
• 数据库已关闭
• 内部数据库错误（如果徽章未正确设置，有时会发生错误）

使用此库的应用程序必须以这种或那种方式处理这些异常。他们可能决定只说“错误”，或者他们可能想要给用户更多有用的信息。在这种情况下，最佳做法是什么？为每种可能性创建自定义异常？使用现有的例外？使用Exception并传递原因（throw new Exception("Badge is deactivated.");）？我认为它是前两种的混合，在适用的情况下使用现有的异常，并在需要时创建新的异常（并在有意义的地方对异常进行分组）。

Answer 1

我基本同意你目前的想法。

• 在适当的地方使用现有的核心异常：ArgumentException，InvalidOperationException等。不要尝试重新调整特定于某些其他模块的异常。使用那些具有明确通用目的的异常，并且不要将它们用于业务规则。例如，InvalidOperationException应表明与您的API有关的错误操作，而不是违反业务规则。
• 对于特定于库的异常，创建一个基本异常类BadgeAuthException，并始终抛出它。具体的场景应该各自得到自己的子类（BadgeDeactivatedException，NoPermissionsAtWorkstationException等等。）这样，应用程序可以根据需要单独处理各个子案例，但它们也可以只捕获泛型{ {1}}如果他们不想讨论具体细节。
• 无论您做什么，请确保BadgeAuthException字段始终包含除例外名称之外的有用信息。

Answer 2

  

使用Exception并传入原因（抛出新的异常（“Badge is deactivated。”）;）

这当然是一种不好的做法，因为它违反了例外的目的 - 不仅仅是表示异常情况，而是提供区分类型级别异常的能力，因此模块的用户可以根据一种例外。

通常，重用标准异常是好的，因为它们可以完全描述代码实际面临的异常情况。在当前情况下提供建议非常困难，因为异常通常取决于语义（参数异常或无效操作异常（例如，可能适用于'他们的徽章已停用'）。

Answer 3

你有两种例外。

特定于您的应用程序的那些，最好避免任何现有的异常。

您的特定于应用程序的异常应该简化使用您的库的人的用例。特定于应用程序的3个例外是用户可以执行的操作。第四个（徽章不存在）显然不是程序性的，但更为严重。

看起来你有两个特定于应用程序的错误：面向用户的事情和管理错误。

其他人是其他技术的一部分;即，数据库错误。你可以 - 通常 - 忽略这些。如果数据库不可用，API将抛出错误，您可以让这些错误通过您的库。

您还可以将这些“包装”为特定于应用程序的异常，其中包含较低级别的异常。如果有很多低级技术，这有时会有所帮助。在您的情况下，它只是一个数据库。忽略它并让数据库错误冒出来。

Answer 4

通过扩展公共基类的细粒度异常类，几乎不会出错。这样，需要专门捕获一些并让其他人通过的呼叫者，以及想要一起处理它们的呼叫者都可以这样做。

Answer 5

我认为你需要为你描述的每个参数设置一个基本异常和一个子类型异常（实际上你可以使db down和内部db错误具有相同的基本异常）。关键是，最好为您的库拥有自己的例外。