抛出选中异常与抛出包装的RuntimeException

Question

在许多地方，我得到了几个已检查的异常，如IOException、ParseException、JSoneException等。我必须做出两个选择之一-

>

通过在方法签名的末尾添加抛出来抛出相同的异常。

将检查的异常包装在RuntimeException（或一些自定义实现）中，然后抛出它，以便调用者不必在任何地方添加throws子句并检查异常。

在第一种情况下，我将不得不到处抛出，但我的客户可以通过捕捉checkedException并继续工作来决定不死。然而，在第二种情况下，RuntimeException实际上可能会迫使客户端失败，因为人们通常不会在任何地方捕捉到泛型/RuntimeException。另外，使用第二种方法可以更容易地使用Java 8 lambda，因为它在检查异常时不能很好地工作。

两者中哪一个更受欢迎？为什么？是否有可遵循的首选实践？

Answer 1

还有第三个选项，即抛出相同的选中异常，但要“软化”它。CheckedExceptions仅在编译时强制执行，通过将异常转换为可丢弃的，您可以安全地抛出它，而不会让编译器抱怨。下面是一个示例实现（在cyclops函数中，我提供了一个库，或者您可以复制和粘贴：））

根据Andy Turner的评论更新简化的ExceptionSoftener类。

public class ExceptionSoftener {


   public static <T extends Throwable> T softenedException(final T e) {
       uncheck(e);
       return e; //never reached.
   }

   private static <T extends Throwable> void uncheck(Throwable throwable) throws T {
       throw (T) throwable;

   }

 }

   public void methodThrowsIOException(){      
       throw ExceptionSoftener.softenedException(new IOException("checked exception, but no declaration required!"));
   }

Answer 2

（1）通过在方法签名末尾添加throws抛出相同的已检查异常：

如果调用方可以从异常中恢复，或者至少必须基于此做出一些决定/取得一些进展，请使用此选项

（2） 将选中的异常包装在RuntimeException（或一些自定义实现）中：

如果调用程序无法恢复，请使用此选项（Spring/Hibernate框架中的大多数异常都遵循此模式）

Answer 3

有两种异常：调用中可能出现的异常和原则上意外的异常（并且应用程序代码可能无法以有意义的方式工作）。对于第一种（例如文件操作的IOException），检查异常（方法签名末尾带有“throws”）非常好。

对于第二种情况，我认为可以将其包装在RuntimeException中，原因如下（不必在任何地方添加抛出）。所有软件都应该准备好在顶层捕获RuntimeExceptions作为“最后一道防线”，否则它们会接受RuntimeException将结束程序（例如对于命令行应用程序来说，这通常是可以接受的）。

第二种情况的一个示例是缺少必要的配置文件。我会将IOException作为RuntimeException重新显示。

顺便说一下，还有第三种经常使用的方法：抛出特定于应用程序的异常。例如，这个异常可以称为“MyConfigurationException”。我认为只有当应用程序能够捕获这个异常并智能地处理它时，这才有用。