抛出异常或返回错误-更好的方法是什么

本文关键字：方法 是什么 更好 返回 错误 抛出异常 | 更新日期: 2023-09-27 18:21:37

处理错误时，最好的方法是什么？将其作为异常抛出还是返回包含错误及其详细信息的对象？

我在想，从系统资源、编码实践和整个企业实践的角度来看，通知错误的更好方法是什么？

我已经看到，在大多数情况下，示例代码抛出一个包含错误信息的自定义异常。但我在想，是否只返回一个从类实例化的对象更好（例如：class DatabaseError）？

我认为在C#中抛出异常可能是资源密集型的，这将涉及（可能）大量的try-catch块。

谢谢！

抛出异常或返回错误-更好的方法是什么

异常通常被认为是将错误条件传递到应用程序链上的首选机制，以便在不导致应用程序完全失败和终止的情况下进行处理和管理。

然而，将异常处理机制用作逻辑路径通常也被认为是一种糟糕的做法——也就是说，使捕获错误条件成为以后更正或替换功能的先决条件（例如，试图打开可能存在或不存在的文件，如果不存在则捕获异常，并因此显示文件浏览器对话框-在本例中，应在尝试打开文件之前检测到"未找到"错误条件，而不是将异常路径视为要求用户定位文件的路径）。

请勿返回错误代码。

例外情况是报告框架中错误的主要手段。

-框架设计指南

有关详细信息和处理性能的方法，请参阅这本优秀的书。

当调用方预期可能发生条件时，最好通过返回代码通知调用方该条件。当出现调用方没有预料到的情况时，最好通过异常通知调用方。

因为大多数语言都没有为被调用的例程提供任何方法来"神奇地"知道调用者在期待什么，所以例程知道调用者在期望什么的唯一方法就是让调用者告诉它

  1. 同时具有"DoSomething"方法和"TryDoSometing"方法。如果不能达到预期目标，前者将抛出异常，而后者将抛出异常。
  2. 使用带有布尔或枚举参数的单个方法，该参数指示例程的行为应为"Try"还是"Do"方法。这通常与小的"DoSomething"answers"TryDoSometing"方法结合使用很有用，它们调用传递适当参数值的组合例程。尽管许多实现都会使组合例程受到保护，但将其公开可能会允许从另一个"Do or Try"例程调用它，从而将ThrowOnFailure值从其他例程传递到内部例程。
  3. 有一个带有重载的方法，重载包括或不包括将用于指示成功或失败的"ref"参数。带参数的函数版本将使用它来指示失败（不引发异常），而不带参数的重载将在失败情况下引发异常。
  4. 有一个带有委托的单一方法，该方法应在失败时调用。从概念上讲，这是一种比传递布尔参数更好的方法，因为委托不仅可以抛出调用代码准备捕获的异常；它还可以设置标志或采取其他操作，这样当调用代码捕捉到异常时，就可以确定实际发生了什么。不幸的是，弄清楚代理的最佳形式，包括它应该采用的参数，是很棘手的。

方法#1似乎是微软推荐的模式，尽管我认为#2可以帮助避免重复编码。方法#3类似于几年前Borland Pascal中使用的约定，它相对直观。第4种方法似乎是最好的，但我还没有弄清楚如何最好地实际操作。

相关文章：