Question

我有一个相当详细的问题，关于包装已检查异常的正确方法，以及Guava执行此操作的方式。（道歉，但我想让我的思维过程失望）

标准的Runnable接口如下所示：

public interface Runnable
{
   public void run();
}

其中run()无法抛出已检查的异常。

因此，如果我想要一个Runnable用于包装抛出已检查异常的任务，并且我打算让调用Runnable.run()的东西处理这些异常，而不是{{1本身，我必须在未经检查的异常中包装异常。

所以有一段时间我在使用：

Runnable.run()

然后我可以在上层处理RuntimeException。除了我认为，我真正想要的是分别处理一个包装的异常，因为我知道它的语义是包装一个已检查的异常，所以我写了这个帮助类：

Runnable r = new Runnable {
   @Override public void run()
   {
       try {
          doNastyStuff();
       }
       catch (NastyException e)
       {
          throw new RuntimeException(e);
       }
   }      
};

然后我可以这样做：

/**
 * Wrapped exception: the purpose of this is just to wrap another exception,
 * and indicate that it is a wrapped exception
 */
public class WrappedException extends RuntimeException
{
    /**
     * @param t any throwable
     */
    public WrappedException(Throwable t)
    {
        super(t);
    }
}

它看起来效果很好。

但是现在我想，好吧，如果我想在库中使用它以及使用该库的应用程序，现在它们都依赖于WrappedException，所以它应该真的在我可以的基础库中包括无处不在。

这让我想到，也许Guava在某个地方有一个标准的WrappedException类，因为我现在默认将Guava包含为依赖项。所以我可以做到

/* place that produces the exception */
...
catch (NastyException e)
{
   throw new WrappedException(e);
}

...
/* upper level code that calls Runnable.run() */
try
{
   ...
   SomeOtherNastyCode();
   r.run();
   ...
}
catch (SomeOtherNastyException e)
{
   logError(e);
}
catch (WrappedException e)
{
   logError(e.getCause());
}

或

throw new WrappedException(e);

或

throw Exceptions.wrap(e);

我只是在Guava中环顾四周，发现Throwables的Throwables.propagate()看起来很相似，但它只包含Exceptions.rethrow(e);中的已检查异常，而不是RuntimeException的特殊子类。< / p>

哪种方法更好？与RuntimeException相比，我不应该使用特殊的WrappedException吗？我的顶级代码想知道添加信息值的最重要的异常。

如果我有一个包装NastyException包装NullPointerException的RuntimeException，包装RuntimeException不会添加信息值，我不关心它，所以我记录的错误将是NastyException。

如果我有一个包含NastyException的IllegalArgumentException，则IllegalArgumentException通常会添加信息值。

因此，在执行错误记录的顶级代码中，我必须执行以下操作：

RuntimeException

这种理念对我来说很合适，但实施感觉很糟糕。有没有更好的方法来处理包装异常？

相关问题：

Answer 1

Spring是我所知道的唯一一个相对类似的库。他们有嵌套的例外：NestedRuntimeException和NestedCheckedException。这些例外情况包含有用的方法，例如getMostSpecificCause()或contains(Class exType)。他们的getMessage()方法返回原因消息（如果包装异常已经有消息，则附加它）。

它在Spring的数据访问异常层次结构中使用。这个想法是每个数据库供应商在其JDBC驱动程序中公开不同的异常。 Spring捕获了这些并将它们转换为更通用的DataAccessExceptions。这样做的另一个好处是，已检查的异常会自动转换为运行时异常。

话虽如此，它并不是非常复杂的代码，我相信你可以在你的代码库中做类似的事情。不需要为此添加Spring依赖项。

如果我是你，我不会尝试打开＆＃34;例外太快，除非你真的可以在那时和那里处理它们。我会让他们冒泡（包装或不包装），使用全局ExceptionHandler来查看他们的因果链，找到第一个＆＃34;有意义的＆＃34;异常，并提取智能错误消息。如果无法这样做，我会打印出＃34;技术错误＆＃34;并在错误消息的详细信息或某种日志中添加整个堆栈跟踪，以便进行错误报告。然后，您可以修复错误和/或抛出更有意义的异常。

Guava的Throwables.getCausalChain()也可能有助于简化异常处理：

Iterables.filter(Throwables.getCausalChain(e), IOException.class));

编辑：

我更多地考虑了你的问题，我认为你不应该真的担心用特定的＆＃34; WrapperException＆＃34;来包装你的异常。类型。你应该使用最合理的东西来包装它们：简单的RuntimeException（Guava＆＃39; s Throwables.propagate()可能在那里有用），RuntimeException带有额外的错误信息，或者适当时更有意义的异常类型。

Java的因果链机制无论如何都会让你找到根本原因。您不应该担心代码中的异常包装。编写一个全局异常处理程序来管理它，并在其他地方使用标准异常冒泡。

Answer 2

通常，最好避免使用未经检查的异常包装已检查的异常（请参阅here和here）。一些解决方法：

使用Callable代替Runnable
使用像Bohemian建议的Executors框架
子类Runnable（或您正在使用的任何接口/类）并添加一些方法来检查事后运行期间的异常，可能是方法public Exception getRunException()或类似。

如果你必须包装一个已检查的异常，我认为最好的方法就像你已经这样做，定义一个RuntimeException的子类。但是如果可能的话，我会尽量避免它。

java：包装已检查异常的标准方法

2 个答案: