代码之家  ›  专栏  ›  技术社区  ›  Kevin Montrose

您希望API如何公开错误处理?

  •  1
  • Kevin Montrose  · 技术社区  · 16 年前

    这个标题需要更多的解释。

    基本上,我正在滚动一个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*(每个都有许多属性)。确实存在攻击性缓存,请求节流以防止无意中拒绝服务器(并禁止调用方的IP)。

    我已经完成了所有这些代码的工作,但目前我在错误处理方面做得不多。基本上,如果API的使用者提供了无效的ID,web服务器关闭,连接超时,或者出现了大量请求层错误,那么访问属性时就会出现异常。

    我认为这远远不够理想。

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

    • 只需将所有异常包装在一些API定义的异常中,并将它们记录为抛出的异常。
    • ErrorHandler
    • 错误时为Null属性,并设置 LastErrorCode .

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

    **这将是。。。维尔德。但它反映了失败的全球性质。这是迄今为止我最不喜欢的想法。

    3 回复  |  直到 16 年前
        1
  •  2
  •   Stefan Steinegger    16 年前

    当您通过一个不存在的id请求一个对象时,您需要告诉调用者什么?如果您只返回null,那么客户机知道它不存在,没有更多要说的了。

    例外情况有两种常见的替代方法。

    • logon 可能会返回一个 LogonResult 而不是抛出异常。
    • 编写两个方法,一个抛出异常,另一个(Try…)返回布尔值。调用方决定是否要忽略“错误”。
        2
  •  2
  •   Alex    16 年前

    API

    我非常喜欢这种让最终用户决定如何处理内部异常的方法,因为除非您的API非常具体,否则很难抢占所有场景。

        3
  •  0
  •   hhravn    16 年前

    我宁愿在发生不好的事情时,有一个异常向我抛出。异常(对我来说,无论如何)是判断出错的常用方法,我发现捕获异常比检查返回值是否为null并检查另一个属性以查看出错的地方更直观。。