http2-client icon indicating copy to clipboard operation
http2-client copied to clipboard

Properly expose errors/exceptions

Open lucasdicioccio opened this issue 8 years ago • 3 comments

It's about time we start exposing errors and exception to API users. The new dispatch mechanism allows to have fewer entry points, which makes the exception handling tracktable.

There are two broad types of errors we may want to catch and expose differently:

  • connection errors (e.g., dead endpoint) and goaways
  • individual stream resets

Currently the design was mostly ad-hoc, with a mix of HTTP2 errors and uncaught exeptions.

lucasdicioccio avatar Nov 19 '17 17:11 lucasdicioccio

I've added a schema of the current threading+error propagation model, showing a risk of leaking low-level asyncs if a remote/the kernel does not close TCP and no-one called an explicit close on the RawConnection object.

https://docs.google.com/presentation/d/1WxP7HkTHy7Rr8sA-9NydD5jRcWbFffW2yM4Pv61OCfI/edit?usp=sharing

The schema doesn't go in some level of detail (e.g., using race around the IncomingLoop to handle cancellation gracefully so that the 'pollSTM' error does not bubble up on a client-initiated close -- cf. #56 .)

lucasdicioccio avatar Feb 06 '18 22:02 lucasdicioccio

The branch https://github.com/lucasdicioccio/http2-client/tree/stop-polling-on-eof is already likely adding an ExceptT layer to collect exceptions, currently hiding everything out of the existing user-facing APIs.

lucasdicioccio avatar Feb 13 '19 00:02 lucasdicioccio

#67 Has done much of the basics needed for this. More work is required for synchronized error handling across threads (for now it's unclear who-gets-what-errors on an exception and, as far as I can tell, users should carefully link asyncs to be double safe).

lucasdicioccio avatar Apr 21 '19 15:04 lucasdicioccio