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 <bjouh...@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@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to