runZonedGuarded的onError接未捕获异常？try/catch为何失效？

1. 为何会出现两个看似相同的异常？ #

这是因为http.Client关闭时会触发两处异常抛出：

• 第一处是你在request方法里await的请求Future抛出的异常，被外层的try/catch直接捕获——这是请求发起后因Client关闭导致的直接异常。
• 第二处是http库内部未被包裹在try/catch中的异步操作抛出的异常：当Client关闭时，它会终止底层的Socket连接，而此时可能还有未完成的Socket事件流（比如响应体的读取流）在后台运行，这些流抛出的异常没有被请求代码的try/catch覆盖，最终流入runZonedGuarded的全局异常回调。
  这两个异常本质上是同类型（SocketException）、同原因的不同抛出实例，所以看起来相同。

2. 为何onError接收的未捕获异常栈trace包含try/catch？ #

异常的栈trace记录的是整个调用链路的执行路径，而非仅未被捕获的部分。虽然你的try/catch捕获了请求Future的异常，但未捕获的Socket异常是从同一个请求上下文的后续异步操作中抛出的，它的调用栈会回溯到请求发起的起点（包括try/catch所在的方法），所以栈trace里会包含try/catch的位置——这并不代表异常是从try/catch里抛出的，只是记录了异常关联的请求是从哪里发起的。

3. 如何捕获该未捕获异常？ #

有两种可靠的处理方式：

• 方式一：确保请求全生命周期的异常被捕获
  不要仅依赖await client.get(...)的try/catch，还要处理响应体流的异常。比如用Response的bytes或body方法时，要包裹在try/catch里：

  try {
    final response = await client.get(Uri.parse('xxx'));
    try {
      final body = response.body;
      // 处理响应体
    } catch (e) {
      // 捕获响应体读取时的异常
    }
  } catch (e) {
    // 捕获请求发起时的异常
  }
  

• 方式二：在runZonedGuarded中过滤或处理该异常
  如果你确认该异常是Client关闭时的预期行为，可以在全局异常回调中针对性处理：

  runZonedGuarded(() {
    // 你的应用代码
  }, (error, stack) {
    if (error is SocketException && error.message.contains('Connection closed')) {
      // 忽略或记录预期的Client关闭异常
      return;
    }
    // 处理其他未捕获异常
  });
  

另外，关闭http.Client时尽量使用默认的client.close(force: false)，它会等待未完成的请求结束后再关闭，能减少这类异常的触发。

内容的提问来源于stack exchange，提问作者Chuck Batson