我正在试图弄清楚正在写的库的正确形式是什么.我需要处理的一个例子是将用户登录到工作站.他们通过扫描徽章来做到这一点.可能出错的可能包括:
使用此库的应用程序必须以这种或那种方式处理这些异常.他们可能决定只说"错误",或者他们可能想要给用户更多有用的信息.在这种情况下,最佳做法是什么?为每种可能性创建自定义异常?使用现有的例外?使用Exception并传入reason(throw new Exception("Badge is deactivated.");)?我认为它是前两种的混合,在适用的情况下使用现有的异常,并在需要时创建新的异常(并在有意义的地方对异常进行分组).
JSB*_*ոգչ 11
我基本上同意你目前的想法.
InvalidOperationException应指出与您的API有关的错误操作,而不是违反业务规则.BadgeAuthException,并始终抛出它.具体的场景应该各自得到它们自己的子类(BadgeDeactivatedException,NoPermissionsAtWorkstationException等等).这样,如果需要,应用程序可以单独处理各个子案例,但如果他们不想详细说明,他们也可以捕获通用子句BadgeAuthException.Message字段始终包含除例外名称之外的有用信息.使用Exception并传入原因(抛出新的异常("Badge is deactivated.");)
这当然是一种不好的做法,因为它违反了异常的目的 - 不仅仅是表示异常情况,而且提供了区分类型级别异常的能力,因此模块的用户可以根据类型的不同来做出决定.例外.
通常,重用标准异常是好的,只要它们可以完全描述代码实际面临的异常情况.在当前情况下提供建议非常困难,因为异常通常取决于语义(参数异常或无效操作异常(例如,可能适用于'他们的徽章已停用').
你有两种例外.
那些特定于您的应用程序的,避免任何现有异常的好处.
特定于应用程序的异常应该简化使用库的人的用例.特定于应用程序的3个例外是用户可以执行的操作.第四个(徽章不存在)显然不是程序性的,而是更严重的.
看起来您有两个特定于应用程序的错误:面向用户的事物和管理错误.
其他是其他技术的一部分; 即数据库错误.你可以 - 通常 - 忽略这些.如果数据库不可用,API将抛出错误,您可以让这些错误通过您的库.
您还可以将这些"包装"为特定于应用程序的异常,其中包含较低级别的异常.如果有很多低级技术,这有时会有所帮助.在您的情况下,它只是一个数据库.忽略它,让DB错误冒出来.