A Result class for functions that may return errors

Isiah Meadows isiahmeadows at gmail.com
Wed Oct 19 12:39:06 UTC 2016


Inline

On Tue, Oct 18, 2016, 18:23 Josh Tumbath <josh at joshtumath.uk> wrote:

> The issue with that, though, is returning `undefined` is really no
> different to returning `null` in a sense. Null is considered bad because
> errors can crop up from not handling null as a return value from a
> function. Using `undefined` does not solve the problem. It also isn’t able
> to explain the failure if there could be multiple reasons.
>

That's just dynamic languages and duck typing for you - if you don't return
the right type or verify what you get, it'll gladly let you shoot yourself
in the foot. (The classic `TypeError: undefined is not a function` is much
easier to debug than getting a superclass instance when I wanted the
subclass one, though.)


>
> But in cases where we do want to identify the reason for a failure and
> it’s not necessarily exceptional, ES does not currently provide a standard
> way to handle such an instance. Over the years, I’ve gone for using
> try..catch anyway in such instances, but many of my colleagues would
> disagree.
>

I probably suspect you're a fan of TypeScript (which now has support for
nullable types) or some other language with static typing. As for getting
the reason of failure, that's when I usually roll my own abstraction
(usually an object with a boolean + value). Several functional languages
and libraries have an `Either` or equivalent, which is nice, but it's a
conceptually simple thing to write if the language doesn't support it.

Partially off topic, but my main use case was catching a possible exception
(that the user might throw unintentionally, but my end has to be defined),
in which I just created a boolean + value object literal to pass around. No
need for a new constructor. That's why I'm not sure how useful it could be
as a language addition.

>
>
>
>
> *From: *Isiah Meadows <isiahmeadows at gmail.com>
> *Sent: *18 October 2016 23:15
> *To: *Bruno Jouhier <bjouhier at gmail.com>; es-discuss at mozilla.org
> *Subject: *Re: A Result class for functions that may return errors
>
>
>
> 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/20161019/a91d8b2f/attachment.html>


More information about the es-discuss mailing list