HTTPServerRequestHandler.handle shouldn't throw

[guoye-zhang]

Errors from handling a single request can't fail the entire HTTP server, so the error thrown here is ignored. We should instead force users to catch and handle the error.

[czechboy0]

What about cancelation, or other reasons the server detects it's now malfunctioning and needs to abort?

[guoye-zhang]

That ties to #120, I think there should be an explicit API to specify what kind of abnormal closure the server intends to signal, since it affects whether the client can automatically retry. Maybe it could be modeled as a typed throw, or a return value?

Today it is ambiguous what throwing an error would do, does it send a 503 response? Resets the stream with H3_INTERNAL_ERROR?

[czechboy0]

Yeah I think it should be represented by a thrown error. The concrete server implementations might have various conditions under which the whole server stops working, and should have a natural way to signal that to their calling code.

[guoye-zhang]

I’m not saying that serve shouldn’t throw, I’m saying that handle shouldn’t throw since the error is just getting swallowed at this moment.

[czechboy0]

Gotcha. Yeah I think cancellation is still an interesting one though.

[FranzBusch]

I am not yet convinced that the handle shouldn't throw. Right now the error is swallowed but a reasonable implementation but use this to issue RST_STREAM or close the connection. There is an ergonomic trade-off here for the user. If we disallow throwing then they must handle errors. @gjcairo what do you think?

[czechboy0]

Do we have any precedent for an API where we invoke user code with async without throws?