【问题标题】:Wrapping an exception when wrapping a third-party library包装第三方库时包装异常
【发布时间】:2015-06-28 13:01:00
【问题描述】:

我在使用 FIDO 设备为注册和登录网站的后端代码制作一个简单的 API 时遇到了一个小问题。

我基本上是在包装 yubico u2f 库并使其更易于使用。我遇到的问题是异常,我想从我的 API 向后端服务器抛出 com.yubico.u2f.exceptions.NoEligableDevicesException 异常,但我不希望我的用户(后端开发人员)看到或导入 yubico 库.

因此我的解决方案是像这样包装该异常:

package com.github.dkanellis.fikey.exceptions;

import com.yubico.u2f.data.DeviceRegistration;

public class NoEligableDevicesException extends com.yubico.u2f.exceptions.NoEligableDevicesException {
    public NoEligableDevicesException(Iterable<? extends DeviceRegistration> devices, String message, Throwable cause) {
        super(devices, message, cause);
    }

    public NoEligableDevicesException(Iterable<? extends DeviceRegistration> devices, String message) {
        super(devices, message);
    }
}

然后throw 给用户我包装了 yubico 异常的异常。问题是这增加了我的代码的复杂性,每次出现com.yubico.u2f.exceptions.NoEligableDevicesException 异常时,我都必须捕获它并抛出com.github.dkanellis.fikey.exceptions.NoEligableDevicesException

有没有更好的方法来做到这一点?

【问题讨论】:

  • 我看不到。 (旁注:使用com.github 作为你的基础包可能不是一个好主意,除非你真的在为 GitHub 工作。)
  • @RedRoboHood 我记得人们说如果你没有网站就这样做(因为基本上通过 github 个人资料是我的网站)。对于没有网站的人,还有其他更好的约定吗?
  • 没有看到你的代码和抽象级别很难说。您应该做的是使用已经包装异常的内部方法。然后你减少这些地方。如果您以 1:1 封装 API,这将不起作用(但您声明不这样做)。
  • 我不确定。 GitHub 是否鼓励这种约定?
  • @assylias 我相信 OP 想说的是 NoEligableDevicesException 是一个检查异常。如果 OP 库中的方法抛出此异常,API 的用户将不得不捕获或重新抛出此异常。 OP 不希望 API 的用户依赖底层库代码。如果 OP 将来选择使用另一个库,API 的用户将继续依赖包装的 Exception 类,而无需担心 API 下使用的是什么库。

标签: java exception wrapper libraries fido-u2f


【解决方案1】:

问题在于这增加了我的代码的复杂性,并且每次发生 com.yubico.u2f.exceptions.NoEligableDevicesException 异常时,我都必须捕获它并抛出 com.github.dkanellis.fikey.exceptions.NoEligableDevicesException。

这不是问题。这实际上是在应用程序的不同层之间传播Exception 的推荐方法。我最近遇到了this 传播Exception 的优秀文章。 (这是一篇 .Net 文章,但仍适用于 Java)

将实际的 Exception 包装到您自己的 Exception 子类中,您可以灵活地更改 API 的底层依赖项,而不会破坏客户端代码。客户端代码继续依赖于您的 Exception 子类。

【讨论】:

  • @AkiK 看看面向方面的程序。可能有一个使用 AOP 的解决方案,它负责包装和抛出您选择的异常,而无需在每个方法中手动执行。我会将此添加为我的答案的一部分,但这不是我尝试过的东西,所以不能确定它是否有效。
  • 因为现在我的代码中出现的异常包装很小,我可能会保持简单并自己包装它,但将来我可能会遇到更多我会使用 AOP,这个是当前的代码,我只是发生了几次这种情况goo.gl/45dfHa
猜你喜欢
  • 1970-01-01
  • 2010-11-02
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2012-07-23
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多