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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20161018/ed56a4f6/attachment.html>

`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 errors and recover from them; 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.

`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.