新的 Iterable<Future>.wait 和 Record<Future, ...>.wait 扩展真的很棒，尤其是记录，允许你在等待同时解析不同类型时保持类型安全。
我以前没有听说过这些，但它们确实看起来非常有用！
然而，它们不能在工具的实现中使用，因为工具的错误处理不考虑等待它们的 ParallelWaitError 可能抛出的异常。
你能详细解释一下吗？这里的预期行为是什么，而你实际看到的行为是什么？

你能详细解释一下吗？这里的预期行为是什么，你看到的实际情况是什么？
抱歉没有说得太具体。当运行一个提供的命令时，工具有错误处理机制来显示任何潜在的错误并以不同的方式适应它们，例如 ToolExit 不会导致崩溃报告。
如果 ToolExit 是由 await (functionThatThrowsToolExit(), functionThatThrowsToolExit()).wait) 产生的，命令运行器只会看到 Package 它的 ParallelWaitError 并将其传递给用户(以及可能的崩溃报告器？)。

好的，现在我明白了。谢谢！
我认为增强 _handleToolError 以处理 ParallelWaitError 是合理的。由于 errors 列表可能包含 ToolExit s 和非 ToolExit s 的任何组合，因此具体应该如何操作并不明显。特别是有几个需要处理的情况：

1. 所有错误都是 ToolExit s 的情况，
2. 所有错误都不是 ToolExit s 的情况，以及
3. 有 ToolExit s 和非 ToolExit s 的某种组合的情况。
   情况1主要是弄清楚我们应该向用户显示什么，这应该不会太难。
   对于情况2,我认为我们可以让 ParallelWaitError 顺利执行。堆栈跟踪将是第一个错误的堆栈跟踪，这将是足够的信息来对崩溃进行分类。这里的缺点是第一个错误实际上会隐藏其他错误。然而，我不认为这是一个严重的问题，除非多个非 ToolExit 错误总是一起发生。更有可能的是(在这个不太可能的情景中),这只会导致一些错误被低报，我认为这是可以接受的。
   情况3可能是最棘手的。我们不能依赖 ParallelWaitError::stackTrace 的默认行为，因为那堆栈跟踪可能是来自一个 ToolExit 的，而它不应该被包含在崩溃报告中。一个想法是简单地 throw 第一个非 ToolExit 。
   或者，对于情况2和3,我们可以为每个非 ToolExit 发送崩溃报告，然后仅使用第一个错误创建崩溃日志和我们向用户显示的链接。这样我们就不会有一项错误掩盖其他错误的风险。
   这些只是一些想法。我很乐意在解决此问题的任何PR中进一步讨论和思考这个问题。

脚注

1. https://dart-review.googlesource.com/c/sdk/+/353080 。我相信错误的消息将包括底层错误中的确切一条消息，但我不确定是否总是 第一 条错误。来自某个本地黑客的一些示例错误消息：ParallelWaitError<List<num?>, List<AsyncError?>>: ParallelWaitError: Null check operator used on a null value ↩

顺便说一下，如果我们之前使用了Future.wait,那么我们已经处理了上述情况。也就是说，我们当然不应该让工具崩溃，但我认为我们可以只显示第一个ToolExit(如果有的话),如果没有，则显示所有错误。我们可以做得更好，但这将是严格优于Future.wait的改进，而不是功能对等。

顺便说一下，如果我们之前使用的是 Future.wait ,那么我们已经处理了上述情况。也就是说，我们当然不应该让工具崩溃，但我认为我们可以只显示第一个 ToolExit (如果有的话),如果没有，显示所有的错误。我们可以做得更好，但这将是对 Future.wait 的严格改进，而不是功能对等。
Future.wait 具有不同的语义，我相信它会急切地与第一个错误一起完成，而 (futureA, futureB).wait 会收集所有错误，然后将它们 Package 在一个新的类型 ParallelWaitError 中。

根据我所知，只有在设置了eager: true的情况下，它才会积极地完成，对吗？否则，它只是恰好没有显示其他错误。