在类内还是类外处理错误?

如果您可以处理一个异常,那么就这样做。如果你做不到,那就让例外情况冒泡到某个可以的人身上吧!

一些一般性的想法:

1. 仅对异常错误条件引发异常。

2. Fail fast.

3. 因为您只针对异常错误条件抛出异常,所以假设您不能在类中修复它,所以异常应该在调用堆栈中冒泡。无论您是在它上面的直接类中处理它,还是在catchall-catch中处理它,都取决于您。

通常,当需要将异常“翻译”到最终用户时,异常处理应该在业务/控制器逻辑/层中完成。因此,不在例如数据层、模型层、视图层和实用程序类中。

通常,捕获运行时异常,如空指针、算术错误、数组索引越界等。 不 完成。它们通常只是表示编程错误。您应该相应地编写代码,这样它们就不会发生(例如 if (x != null) { x.doStuff() } )

如何与异常交互取决于代码在应用层中的位置。一般来说,错误报告是一个用户界面的问题,通常最好留给应用程序(代码的最外层)。

低级代码和中级业务逻辑代码通常在不同的应用程序之间共享。由于不同的应用程序对向用户报告错误的数量和类型有不同的策略,因此低级和中级代码应避免为了报告错误而处理异常。让应用程序这样做。

在低级和中级代码中捕获异常有很多合理的原因,特别是在主路径失败时尝试其他路径,或者将低级异常转换为更特定于当前操作的异常。只是要小心不要过火,使异常陷阱尽可能具体(不要过度泛化,否则会捕获您不准备处理的东西),并且对于完全用中低级代码抑制异常非常关键。

中低级代码的一般原理应该是:如果调用方请求的操作失败,让调用方看到结果——异常。

您的中低级代码通常会自然地分为两类:“硬”功能,它们要么执行请求的操作,要么在无法执行的情况下抛出异常,而“软”功能则更便于进行实验性的探测。如果一个操作大多数时候可能会失败,如“fileexists()”,那么在失败时引发异常并要求调用方将对此函数的所有调用包装在异常处理程序中可能是对异常的不良使用。这将为调用者创造更多的工作。在这个用例中,fileexists()应该是一个返回true/false而不是抛出的“软”函数。此文件的“硬”版本可能称为“RequireFile()”,如果找不到该文件,则将引发此版本。

作为一种命名模式,您经常将“try”作为软函数的前缀。因此,如果getData()不能完成工作,它将是一个抛出的硬函数,而tryGetData()将是一个返回布尔值而不是抛出的软函数。根据使用情况,在类或库中查看这两个函数是很常见的。

这些对通常作为一个调用来实现,另一个调用-getdata()调用try getdata()并在try getdata()返回false时抛出,或者try getdata()在try..catch块内调用getdata()。使用哪种模式取决于函数所做工作的复杂性。如果布尔逻辑很容易检测到故障情况(异常风险低),那么TryGetData将是主要实现。如果失败案例因异常而失败,那么getdata将是主要实现。

“硬”函数允许调用者充分利用异常来简化程序逻辑-如果此调用成功,那么我可以使用调用结果继续下一步。如果此调用失败,它将引发异常,下一步将不会执行。“hard“函数允许您以正确的假设来爆破一系列操作,即每个操作都返回合法的结果,因为如果一个操作不能返回合法的结果,它将把我们从这个操作序列中抛出并爆破出来。这使您可以集中主要路径程序逻辑,而不必处理消防队错误——分析每个调用上的函数错误代码,并决定如何处理它们。

只要你能做出富有成效的反应,你就应该处理异常。如果它必须冒出更高的气泡,那就让它冒出来吧。

我还重新打包异常,只要它们能被低于我的代码的某个层抛出。在Java中调用SQL调用可以看到一个很好的例子。每件事都会抛出一个sqlException,如果我有一个方法可以触发多个异常,但不能处理它们,那么这就没有帮助。通过重新打包,我可以区分失败的连接和构建准备好的语句的问题,并做出不同的反应。

我认为最好的方法可能是混合方法。

在类中执行与类相关的问题的错误处理。例如,如果属性设置器进行验证,则会检测到这些错误并从类中抛出。

在网页或表单级别,您可以在一个方法中处理所有错误。例如,对于ASP.NET Web应用程序,可以使用page_错误方法捕获到达该页的所有异常。然后,显示由类属性设置器引发的错误消息文本。

或者,您可以在每个方法签名中包含一个错误消息字符串返回值。调用页/窗体检查错误消息的内容,并根据上下文决定要做什么。这需要比上述方法更多的编码。

有时,类不知道事件是否实际上是一个错误。例如,如果一个类方法从数据库中选择一条记录并返回其数据,那么该类就不知道这是否是一个错误。如果调用class方法的页/窗体是搜索页,则不返回任何记录不是错误,它是“找不到记录”,并显示该信息。