Question

我有一个反复出现的模式，我在其中并行运行多个任务，要么它们都成功，要么整个过程因其中一个而失败。虽然我可以在第一个任务异常之后确定进程失败，但我必须等到它们全部结束才报告异常。

{
    List<Future<?>> futures = launchTasks();
    boolean anyProcessFailed = false;

    for (Future<?> future: futures)
        try {
            future.get();
        } catch(ExecutionException ex) {
            //This process failed
            anyProcessFailed=true;
        }

    if (anyProcessFailed) throw new Exception();
}

上面的代码有效，但最后引发的异常没有引用导致它的异常，可能是一个或全部。

问题是：使用Throwable.addSuppressed来实现异常的多种原因的概念是一种好的做法，还是应该实现我自己的{{ 1}}暴露Exception？

的类型

我已经读过，在使用公共API时，抑制异常只能在try-with-resources语句中由JRE设置。实际上，try-with-resources是普通老派Throwable[] getCauses()块

的语法糖

示例1：以下代码不会等待其他任务完成，因此其他线程将保持不变。

try-finally

示例2：我目前正在做什么

{
    List<Future<?>> futures = launchTasks();

    for (Future<?> future: futures)
        try {
            future.get();
        } catch(ExecutionException ex) {
            //This process failed
            throw new Exception(ex);
        }

}

Answer 1

通常情况下，实现您自己的异常始终是一种很好的做法，代表代码中非常特殊的情况如果它可以为您的API调用者提供有意义的数据。否则，使用JDK中的一个通用异常将是更好的选择。我认为在addSuperceeded方法的JavaDoc中，提到了try-finally场景作为JDK中此方法的示例用法。如果有意义，你当然可以将它用于你的场景。

Answer 2

问题是：使用Throwable.addSuppressed实现异常的多种原因的概念是一个好习惯，还是应该实现我自己的暴露Throwable [] getCauses（）的Exception类型？

否。在JLS和Throwable API中使用该术语的意义上，这些不是“抑制”异常。
是的，虽然我不会打电话给causes。

抑制异常是收集多个异常的方法

2 个答案: