Re: A Result class for functions that may return errors

. That's why I'm not sure how useful it could be as a language addition. > > > > > *From: *Isiah Meadows <isiahmead...@gmail.com> > *Sent: *18 October 2016 23:15 > *To: *Bruno Jouhier <bjouh...@gmail.com>; es-discuss@mozilla.org > *Subject: *Re: A Result class for

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 wrote: > try/catch is often

Re: A Result class for functions that may return errors

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

Re: Re: A Result class for functions that may return errors

I would also like to point out that V8 is one of few that don't optimize `try-catch`, and both Chakra and SpiderMonkey do optimize them IIRC (the latter has trouble optimizing functions that throw, though). On Tue, Oct 18, 2016, 15:29 Josh Tumath wrote: > > Not sure if

Re: Re: A Result class for functions that may return errors

> Not sure if I'm missing something, but wouldn't it be trivial to code that > constructor in JS? Yes it would be trivial, but my design I came up with was an example. The point I wanted to get across was to have some sort of standard practice for error handling using `return` rather than

Re: A Result class for functions that may return errors

Not sure if I'm missing something, but wouldn't it be trivial to code that constructor in JS? ```js class Result { constructor (type, value=true) { this[type] = value; } } function add(data) { if (data !== Object(data)) { return new Result('error', new Error('The data is not an

A Result class for functions that may return errors

At the moment, when we call a synchronous function that runs some kind of operation, there are two obvious ways of returning whether there has been an error: returning a boolean or throwing an error. Returning a boolean to show whether the operation worked is simple, but doesn't give any