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 mailing list