c# - 您希望 API 如何公开错误处理？

Question

这个标题需要更多解释。

基本上，我正在使用一个 API，将 Web 服务包装在一个很好的分层模型中。该模型以以下形式公开内容:

var obj = MyRemoteResource.GetForId(1234, SourceEnum.ThatSource);
ApiConsumerMethod(obj.SomeProperty);  //SomeProperty is lazily loaded, and often exposes such lazily loaded properties itself
... etc ...

其中有许多不同的 RemoteResources*(每个都存在许多属性)。确实存在积极的缓存，并请求限制以防止无意中对服务器进行 DOS(并禁止调用者的 IP)。

我已经让所有这些代码正常工作，但目前我在错误处理方面并没有做太多工作。基本上，如果 API 的使用者提供了无效的 ID、Web 服务器关闭、连接超时或任何其他过多的请求层错误发生，则异常只会在访问属性时渗透。

我认为这远不理想。

所以我的问题是，我应该如何包装这些错误，以便该 API 的用户可以方便地管理它们？

我考虑过的一些路线:

• 只需将所有异常包装在一些 API 定义的异常中，并将它们记录为已抛出。
• 公开一个静态 ErrorHandler 类，允许用户为特定错误注册通知回调；当没有针对特定错误进行注册时，回退到上述行为。**
• 出错时为 Null 属性，并设置 LastErrorCode。

每种方法都有优点和缺点。我会很感激对他们的意见，以及我没有想到的替代方案。

如果它完全影响讨论，抛出这些异常的平台类是 WebClient .此外，WebClient 的用法非常抽象，如果需要，可以很容易地用其他下载方案替换它。

_{*也就是说，很多不同的类}

_{**这会……很奇怪。但它映射到失败的全局性质。到目前为止，这是我最不喜欢的想法。}

Answer 1

我不会实现花哨的错误技术(例如事件和类似的东西)。判断在何处以及如何使用异常并不容易，但这不是实现其他内容的理由。

当您通过一个不存在的 ID 请求一个对象时，您必须告诉调用者什么？直接返回null，客户端就知道不存在了，没什么好说的。

异常迫使调用者关心它。所以它们应该只用在调用者需要做一些特别的事情的地方。 Exception 可以提供为什么某些东西不起作用的信息。但如果它是用户也可以忽略的“错误”，则异常不是最佳选择。

异常有两种常见的替代方法。

• 使用返回值来提供有关操作结果的信息。例如，logon 可以返回一个 LogonResult 而不是抛出异常。
• 编写两个方法，一个抛出异常，一个(Try...)返回一个 bool 值。调用者决定是否要忽略“错误”。