我目前正在为RESTful Web服务API编写Java Wrapper。
我现在正在尝试清理一些异常处理，并且不确定采取什么方法。这是一个供Java程序员使用的工具，因此我无法像使用最终用户应用程序那样处理它。
如果我有一个方法（连接）包含可能抛出异常的代码，我如何让这些异常浮动到最终程序员？这是否是我应该处理它的方式，取决于它们来捕捉异常？等...
答案 0 :(得分：4)
我建议您从底层API中捕获异常（除非它们真正有意义通过），并抛出一个更适合您的抽象级别的新异常。
如果您不想丢弃异常原因，请使用exception chaining。
答案 1 :(得分：2)
我认为您应该决定现有类型是特定于实现还是库固有的。例如，如果它是一个与网络相关的异常，并且您显然正在制作基于网络的API，那么我只是让它传播开来。无论如何，调用者需要知道这种错误。
另一方面，如果它是一个数据库相关的异常，这只是因为某些奇怪的原因你在嵌入式数据库中查找WSDL，或类似的东西，这显然是可能的不适合调用者必须处理 - 所以抓住它并将其包装在一个更适合你的抽象级别的异常中。
答案 2 :(得分：2)
在任何情况下都必须将异常传递给用户，因为它是一个库。
答案 3 :(得分：0)
问题是你想要你的图书馆是多么不透明。
您向用户抛出的每种异常类型都应该暗示用户可以对此做些什么。例如，
catch (ConnectionException e) {
disconnect();
connectAgain();
}
仅在您的用户有权访问disconnect（）和connectAgain（）时才有效。但是，如果您承诺提供各种连接，那么您的代码应该已经具有此逻辑，如果失败，则抛出一个通用的WrapperException并完成它。
对你来说可能是一个很好的方法是声明你自己的异常类型（并且不要使它成为RuntimeException），捕获你观察到的异常并抛出你的异常。
答案 4 :(得分：0)
我认为它的重要性在于API的作用，以及在哪种情况下使用它。
如果API是演示文稿/渲染层的一部分，那么我宁愿总是返回一些可以渲染，修饰或写入响应流的内容。
如果API要执行（非呈现/ UI相关）处理，那么抛出API逻辑范围之外的任何异常都没有问题。
如果API设计得很好，这些原因显然超出了API的控制范围，或者逻辑上超出了API“知道如何”或“应该”处理的范围，即使它可以捕获/控制它。
当向“用户”返回异常时，我更愿意尽可能返回标准异常而不是单个自定义包装类型。
然而，在我的API实现中，如果它们具有明确且有用的用途，我会经常使用自定义异常类型。
只是我的2美分：）