A Result class for functions that may return errors

Isiah Meadows isiahmeadows at gmail.com
Tue Oct 18 22:15:13 UTC 2016

I agree with this: if a result may fail normally, I would just return a
sentinel value like `undefined` (I usually avoid `null`). If it's truly
exceptional, don't catch it except to log it/etc.

On Tue, Oct 18, 2016, 17:49 Bruno Jouhier <bjouhier at gmail.com> wrote:

> try/catch is often misunderstood as people think that they MUST catch
> errors as close as possible to the point where they may be thrown.
> Good EH practice is exactly the opposite: place a few try/catch in
> strategic places where you can report the error and recover from it; and
> let errors  bubble up (without any EH code) everywhere else. With this kind
> of approach, you have very lean code (not polluted by error handling logic)
> and you keep the exception path separate from the normal execution path.
> This makes it easy to review how errors are handled.
> And try/finally is your friend when it comes to releasing resources and
> restoring program invariants.
> I don't see a need for a special Return class.
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20161018/27b17203/attachment-0001.html>

More information about the es-discuss mailing list