更好地处理连接到 Internet 的方法中发生的异常

Question

我有很多方法可以连接到互联网来获取一些东西。所以我需要处理可能发生的WebExceptions。但我想减少使用这些方法的代码中的 try catch 块，因为它看起来很难看。我现在正在做的是返回一个Tuple 和一个enum，我可以用它来查看方法是失败还是成功等。然后我使用switch 和case 块来处理它。例如：

Tuple<GetIpReturn, string> ip = await _user.GetIp();
GetIpLocksReturn returnValue = ip.Item1;
switch (returnValue) {
    case GetIpLocksReturn.InternetError:
        // WebException occured
        break;
    case GetIpLocksReturn.AuthError:
        //
        break;
    case GetIpLocksReturn.Success:
        // Use ip.Item2 (The ip string)
        break;
}

但是，这些 break 语句看起来也很混乱。
通常错误案例的代码行数很少。有没有更好的方法来做到这一点？ （也许使用委托？）

Answer 1

恕我直言，您应该让异常发生。在包含失败代码的返回值中包装异常与正常的 .NET 习惯用法是对立的，在调用者和被调用者中都需要更多代码（包括额外的 try/catch 处理所增加的运行时成本），并且没有实现任何不能做的事情使用异常来实现。

将异常转换为失败代码也会丢失潜在有用的信息，例如堆栈跟踪和HRESULT 值。

请注意，如果您想向异常添加信息，您的实现可以捕获发生的异常，然后抛出一个新的自定义异常，您已为此提供了原始异常 InnerException属性值。

相关讨论另见：
C# why throw errors
Should my method throw its own exception, or let .NET throw if a file doesn't exist?

它们不是完全相同的问题，但它们都包含关于为什么在 .NET 代码中首选异常的讨论。

Answer 2

我的回答是关于 已处理 异常，这意味着它已经发生了足够多的情况，我们知道如何处理它；这是例行公事。例如，在我的应用程序中，我们只是在这些定义明确的情况下向用户显示一条消息。当然，这取决于应用程序。我同意 Peter 的观点，未处理的异常应该进入 catch，而不是 switch。

只需返回一个包含 a) 友好错误消息或空白、b) 数据和 c) 布尔成功的类。您也可以将状态代码和/或异常数据放入其中以进行调试。通常，如果不是 Success，您只想显示或记录错误消息，通常您只想在 Success = true 时使用数据。成功告诉你api调用后是否可以继续。

总而言之，OO 来拯救。尝试使返回类更强大，以便您可以根据您知道最终将使用这些属性执行的操作（例如，显示错误消息）消除切换。