The dart websocket/http/socket libraries frequently throw errors with no meaningful stack traces attached. This makes it difficult to identify parts of the flutter_tool code that need additional error handling. Generally what I'd like is for errors thrown during the course of a particular request to contain a stack trace that was created where the user code initiated the request.

This can easily happen if a Completer is completed with an error but no stack trace, though there are other constructs that have a similar effect:

• https://github.com/dart-lang/sdk/blob/master/sdk/lib/_http/http_impl.dart#L1850
• https://github.com/dart-lang/sdk/blob/master/sdk/lib/_http/http_impl.dart#L1607
• https://github.com/dart-lang/sdk/blob/master/sdk/lib/_http/http_impl.dart#L1620
• https://github.com/dart-lang/sdk/blob/master/sdk/lib/_internal/vm/bin/socket_patch.dart#L779

A related example from the socket_impl: the following code does not return a meaningful stack trace, printing an empty string for the stack trace.

import 'dart:io';

Future<void> main() async {
  try {
    await foo();
  } catch (err, st) {
    print('err: $err, st: $st');
   }
}

Future<void> foo() async {
  await WebSocket.connect('ws://localhost:8181/ws'); // Nothing actually running here
}

Some of the other errors are harder to hit, but hopefully the SDK has an existing http test suite that could be exercised here.