Re: A Result class for functions that may return errors
Inline On Tue, Oct 18, 2016, 18:23 Josh Tumbath 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 > *Sent: *18 October 2016 23:15 > *To: *Bruno Jouhier ; es-discuss@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 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
Re: Re: A Result class for functions that may return errors
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. 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. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
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 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
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 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
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 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 `throw`, akin to how `Promise` > gives us a standard design and encapsulation for asynchronous code. > ___ > 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
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 `throw`, akin to how `Promise` gives us a standard design and encapsulation for asynchronous code. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
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 object.'));
}
return new Result('success');
}
console.log(add({}).success); // true
console.log(add(12).error.message); // 'The data is not an object.'
```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
