【发布时间】: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