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

Rya*_*ins 11 exception

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

  • 他们的徽章已停用
  • 他们没有在这个工作站工作的许可
  • 扫描的徽章在系统中不存在
  • 他们已经登录到其他地方
  • 数据库已关闭
  • 内部数据库错误(如果徽章没有正确设置,有时会发生)

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

JSB*_*ոգչ 11

我基本上同意你目前的想法.

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


n53*_*535 8

使用Exception并传入原因(抛出新的异常("Badge is deactivated.");)

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

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


S.L*_*ott 6

你有两种例外.

那些特定于您的应用程序的,避免任何现有异常的好处.

特定于应用程序的异常应该简化使用库的人的用例.特定于应用程序的3个例外是用户可以执行的操作.第四个(徽章不存在)显然不是程序性的,而是更严重的.

看起来您有两个特定于应用程序的错误:面向用户的事物和管理错误.

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

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