Better error handling

[cprussin]

We need better sad-path handling. Things like:

• [ ] Request closed by client while in flight
• [ ] Exception while running router
• [ ] Others?

[cprussin]

@rnons provided an example (see https://github.com/cprussin/purescript-httpure/issues/124); quoting here:

Hi, I'm trying to use httpure to write a simple backend. It's a bit strange when an error is > thrown, there is no way to see it. I have a reproducible example: https://github.com/rnons/play-with-httpure/blob/error/src/Main.purs#L13

curl http://127.0.0.1:8080 get

< HTTP/1.1 500 Internal Server Error
< Content-Length: 0
< Date: Sat, 27 Oct 2018 01:56:31 GMT
< Connection: keep-alive
<
* Connection #0 to host 127.0.0.1 left intact

Open http://127.0.0.1:8080 in browser get

This page isn’t working
localhost is currently unable to handle this request.
HTTP ERROR 500

In the terminal where I run node server.js, there is nothing. There is no error message anywhere, which makes debugging a bit difficult.

[akheron]

We currently transform uncaught JavaScript exceptions to a 500 without any error message. Would it be better to crash the server and print the traceback to console? Would this direct users to catch errors themselves, or to use quality libraries that don't let uncaught exceptions through?

[cprussin]

@akheron I would prefer to come up with some modification to the httpure api which forces users to handle uncaught exceptions in routes. I don't think there's a way to guarantee routes themselves are exception free now that there's no row type for Effect, so I think the best approach is the always assume any route could throw and make httpure consumers tell us what to do in that case.

[akheron]

It's not possible to ensure that JavaScript exceptions have been caught on type level. There's a plan to do something about this in Aff: https://github.com/slamdata/purescript-aff/issues/137

[akheron]

... and because it's not possible on type level, I don't really see a way to enforce this other than crashing the server.

It seems to me that if the aforementioned change was made to Aff, uncaught JavaScript exceptions would more or less crash the computation. You'd have to use supervise to catch them and do something, but that wouldn't still be visible on the type level.

[cprussin]

So what I had in mind was that we would just catch all exceptions and pass them off to a user-defined handler; so essentially we would force users to write the exception handler.

But the more I think about it, the more I think you're right: if there's no enforcement on the type level, then users are no better suited to handle exceptions than we are. The fact is, if an exception occurs, the system is in an unintended and unpredictable state and should be crashed.