Question

我写了一个安静的网络服务。 restful Web服务的合同是接收参数，通过SSL与外部服务通信并回复客户端。服务合同和服务没有问题。服务设计很好，所有已检查的异常都已在catch块中捕获，但经过一些服务测试后，似乎未经检查的异常未得到正确处理。是否有任何方法可以使用域异常封装这些未经检查的异常。简单来说，如何处理或预测未经检查的异常。

Answer 1

您应该在代码中始终只有一个位置来处理所有异常，并且您所描述的内容听起来像是乱七八糟地处理代码，无论何处调用声明已检查异常的方法。在遇到已检查异常的低级代码中使用此代码：

try { 
  ...
catch (RuntimeException e) { throw e;} 
catch (Exception e) { throw new RuntimeException(e); }

在异常屏障（提到的中心位置）使用

try {
  ...
catch (Throwable t) { // logging, returning error response, whatever
}
finally { // global resource cleanup
}

只有在特殊情况下才需要做更多的事情，您会发现在代码库中并不常见，也就是说，您的低级方法获取了为每个请求获取的资源之外的资源。一个例子可能是文件I / O.在这种情况下，当然必须使用try-finally来处理额外的资源，但您仍然不能catch并吞下例外：主要的异常障碍仍然需要知道存在问题并进行清理。

Answer 2

在一个宁静的Web服务的特定情况下，该框架有一个“catch-all”处理程序，可以执行您不喜欢的操作。因此，在这里反对其他一些答案，添加更多或不同的处理没有任何恶意。框架的处理程序肯定不会为您清理，因此您只能通过清理自己来改善事情。因此，您有两种选择。

您可以根据JAX-RS标准将异常映射器添加到提供程序列表中。
您可以将代码包装在Throwable的try / catch中，然后在catch处理程序中构造一个吸引您的响应。

在不知道您用于JAX-RS的工具包的情况下，我无法更详细地了解（1）。

Answer 3

RuntimeExceptions应该指示编码错误，所以理想情况下你应该修复错误而不是试图处理它们。不幸的是，一些图书馆开发人员滥用RTE来处理非bug并迫使你抓住它们。您可以在异常中包装RuntimeException。

....
catch (RuntimeException e) {
    throw new MyCheckedException("Failed to...", e);
}

编辑：这些日子似乎是一个有争议的观点。我知道糟糕的检查异常可能会很痛苦。但是，使用已检查的异常可以帮助客户和实施者理解合同。对于非错误使用RuntimeExceptions可以更容易地在“快乐的情况下”使用API，当你不关心异常时，但是当你这么做时，更难以知道对“悲伤情况”的期望。它还使接口的实现者更难以知道它们的期望 - 它们是否被允许抛出的RuntimeExceptions等。

Java域例外

3 个答案: