4 ms·
I really wish more devs would treat errors as first class, the same level of importance as a success response. We had an error page at a previous job that had
by jcpst 4y ago
I really wish more devs would treat errors as first class, the same level of importance as a success response.
We had an error page at a previous job that had an <h1> OOPS!. Not sure who made it, but they didn’t think much of it, and a lot of users really didn’t like it.
- mmmpetrichor 4y agoLet's make a distinction between errors delivered to users buying a train ticket on an app (as in the original article) and errors meant for developers. It feels like hardly anyone in the thread is making that distinction.
- titzer 4y agoThis is why I have grown to hate expressing errors as exceptions. Nowadays, I handle errors one of two ways: it's either part of the return value of the function (i.e. an error state, usually a case of a variant), or the caller passes an error handler object, with the default behavior is the error handler records a list of things that went wrong. Threading the error handler through generally isn't too bad; then you can check it whereever you want and handle it at the top level. It's almost impossible to swallow an error unless you create a new error handler object and throw it away, which would be a very rude thing to do. This works especially well for parsing data, as you can write most of the parser completely oblivious of previous errors and keep on truckin'. The top-level parse routine will surface the first lexicographical error. The code is very clean but still gives really good error messages (and multiple! I used this for the Virgil parser and entire compiler).