抛出异常或返回错误 - 更好的方法是什么？ [关闭]答案

【问题标题】：Throwing an exception or returning an error - What is the better approach? [closed]抛出异常或返回错误 - 更好的方法是什么？ [关闭]
【发布时间】：2012-01-28 17:55:19
【问题描述】：

处理错误时有什么更好的方法 - 将其作为异常抛出或返回包含错误及其详细信息的对象？

我在考虑通知错误的更好方法是什么——就系统资源、编码实践和整体企业实践而言？

我见过在大多数情况下，示例代码会引发包含错误信息的自定义异常。但我在想是否最好只返回一个从类实例化的对象（例如：类 DatabaseError）？

我相信在 C# 中抛出异常可能会占用大量资源，这将涉及（可能）大量的 try-catch 块。

谢谢！

【问题讨论】：

你在说什么样的错误？预期的？意外？您的模型中完全不正确的情况？
exception-handling 的可能重复项。
@oded - 没什么特别的，只是一个一般性错误。我的想法是如何告诉函数的调用者发生了错误以及有关错误的信息。我认为抛出异常有点过分。但似乎它是最好和推荐的方式。
@John Saunders - 感谢您的链接。似乎对于同一个问题已经有很多答案了。对不起，我没有先检查，我认为这真的是一个非常初学者的问题。
这里有很多初学者。任何初学者的问题都已经被问过了。

标签： c# winforms exception exception-handling

【解决方案1】：

异常通常被认为是将错误条件沿应用程序链向上传递到可以处理和管理的首选机制，不会导致应用程序完全失败和终止。

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

【讨论】：

感谢 Jonners 的洞察力。因此，在这个想法中，告诉调用者某些事情不正确以及有关它的一些信息的方法是什么（例如：找不到他们试图打开的文件）。所以实际上，这取决于我如何告诉呼叫者有错误，这是信息。大多数人似乎都指向使用异常处理，但我也很欣赏你的观点，即使用异常作为通知琐碎错误的全部方法并不是一个好习惯。
@codex10 - 我认为 Jonners 指的是 Tester-Doer 模式 - 如果有一种方法可以在调用方法之前检查错误情况，通常是一个好习惯这样做。还有 Try-Parse 模式。
@codex10 - 是的，就是这样。重点不是限制传递给用户的错误信息，而是尽量确保异常处理机制不用作逻辑流程的一部分——在操作之前测试可能的失败条件，然后使用异常机制，以在出现问题时提醒用户仍然出错。

【解决方案2】：

请勿返回错误代码。

异常是在框架中报告错误的主要方式。

-Framework Design Guidelines

有关详细信息和处理性能的方法，请参阅那本出色的书。

【讨论】：

【解决方案3】：

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

因为大多数语言都没有为被调用例程提供任何“神奇地”知道调用者期望什么的方法，所以例程知道调用者期望什么的唯一方法是让调用者告诉它。我建议以下几种模式：

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

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

【讨论】：