On 11/12/14, 4:10 PM, Kevin Smith wrote:
The only thing they couldn't do (under this proposal) is expose
the promise being used to userland (to eliminate the chance for
userland to hold on to the promise and expect to be able to add an
error handler at any time).
And lose the ability to combine the results of async functions with
"all", "race", and any other promise combinator? That's a core
strength of the current design.
A very good point.
Crazy, half-baked idea: Move the "forwards" vs "throws/logs" distinction
to the callsite (in sync contexts only?) rather than the definition
context as was described at the beginning of this thread.
The thought-process running along the lines of making the default
behavior to log/report, but with an escape hatch when logging is *not*
what you want.
It's easier to notice an undesired log (and suppress it if necessary)
than it is to notice that a log is *missing* in exceptional circumstances.
```javascript
async function asyncLibrary(data) {
// ...
}
function doStuff() {
// Becomes sugar for something like
// asyncLibrary(badData).catch(err => {
// console.error(err);
// throw err;
// });
//
// This makes logging-to-console the default
var toplevelResult = asyncLibrary(badData);
// No additional .catch() -- just pushes new syntax to discourage
// swallowed-by-default. When you want this "storing" behavior, you
simply
// opt-in to it via syntax (or a stdlib?) rather than opting out
var storedResult = ^asyncLibrary(badData);
// For combinators, you get something like:
Promise.all([
^asyncLibrary(data1),
^asyncLibrary(data2)
]);
}
async function doOtherAsyncStuff() {
// This stays status quo
try {
asyncLibrary(badData);
} catch (e) {
// caught!
}
}
```
(Frankly the `^` syntax I used here seems a bit arcane to me -- but
maybe someone can see through it and can think of a more expressive syntax?)
-Jeff
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
