2

我正在编写一个库，在其中我在内部使用检查的异常，因为它有助于确保所有路径都处理某些异常情况。但是，由于我使用了以下规则，我不想给我的图书馆用户带来这些检查异常的负担：

只有在调用者和接收者都无法控制的情况下，才应检查异常。

由于大多数内部检查异常都指向配置问题或其他在正确设置中永远不会发生的问题（因此可以由用户解决），因此我希望在我的 API 边界处将这些作为未经检查的异常公开。

通常，我会将这些检查的异常包装在未经检查的变体中并完成它。但是，在这个库中，我有时已经有 3 级异常嵌套，例如：

hs.ddif.core.inject.instantiator.CheckedInstantiationException: Exception while constructing instance via Producer: hs.ddif.core.inject.instantiator.InstantiatorTest$H hs.ddif.core.inject.instantiator.InstantiatorTest$B.createH()
(...)
Caused by: java.lang.reflect.InvocationTargetException
(...)
Caused by: java.lang.RuntimeException: can't create H

在顶部添加另一个级别（这不会真正添加任何相关信息）使得更难看到根本原因，并且需要instanceof检查getCause用户代码是否确实想要进行特定处理。我目前这样做：

catch(CheckedInstantiationException e) {
    throw new InstantiationException(e);  // convert to runtime at API boundary
}

但是，如果我这样做了怎么办：

catch(CheckedInstantiationException e) {
    throw new InstantiationException(e.getMessage(), e.getCause());  // convert to runtime at API boundary
}

这会剥离一个嵌套级别，但会保持跟踪完整。跟踪看起来略有不同，但仍包括所有涉及的行。

我的问题是，这种方法是否有我遗漏的缺点？

4

0 回答 0