5 ms·
> Coming from other languages such as Python, Ruby or PHP you’d expect throwing and catching errors, or even returning an error from a function would be a strai
by spion 11y ago
> Coming from other languages such as Python, Ruby or PHP you’d expect throwing and catching errors, or even returning an error from a function would be a straightforward way of handling errors. Not so with Node. Instead, you get to pass your errors around in your callbacks (or promises) - thats right, no throwing of exceptions.
Promises let you throw errors normally. They will propagate up the call stack in a similar manner. With bluebird, you will also get full stack traces in development mode and the performance penalty for that isn't too bad.
> The last thing that I found frustrating was the lack of standards. Everyone seems to have their own idea of how the above points should be handled. Callbacks? Promises? Error handling? Build scripts?
Promises are in ES6 (i don't think it gets more standard than that) and have well defined semantics, including error handling, shared between libraries: https://promisesaplus.com/ https://promisesaplus.com/
I know that Bluebird's promisifyAll might seem like a bit of a hack, but just try it out. It works surprisingly well, and its really painstaikingly tuned for near-zero performance loss. It will probably be both less painful to do and more performant than any manual attempt to wrap a callback based API into a promise one.
- pjungwir 11y agoI gave a talk about handling errors in Node a few years ago: https://github.com/pjungwir/node-errors-talk https://github.com/pjungwir/node-errors-talk At the time the solution was "use domains", but I think domains are deprecated now. It was painful enough that I have stuck with Rails since then. I'm glad to hear that Promises are an improvement!
- koolba 11y agoDomains have been deprecated since at least 0.10. As of yet there's no replacement for them and all node apps should be using them. There's no other way to catch "But ... but ... that can't happen!" type errors.
- spion 11y agoThere is no replacement because they're a fundamentally broken idea. They require the following to happen, in that order: * V8 needs to optimize try-finally * Node core needs to add try-finally at every single place where callbacks are invoked and make sure all state and resource cleanup is properly done to support domains * Popular libraries need to also add try-finally handlers for the above. As to why this is a problem in node and not so much in other languages, its because with node callbacks, the call stack goes both ways. In other languages, libraries mostly call their dependencies' code. In node's CPS style, you call the library but the library also calls your closure code. The semantics for the 2nd part aren't well defined in node - the loose law basically says: I wont call you twice, I'll try not to call you synchronously, and you wont throw (and if you do the behavior is undefined). With promises there is a contract and its enforced by the promise implementation. Since Promises actually have error semantics, you can build resource management strategies on top of them. http://promise-nuggets.github.io/articles/21-context-managers-transactions.html http://promise-nuggets.github.io/articles/21-context-manager... - and consequently there is no reason to crash your server on errors.
- lobster_johnson 11y agoDomains are used for another reason: To emulate thread-local variables. I hope that support is not going away, because it's really handy.
- spion 11y agoIts interesting that the same problem (TLS) can also be solved with something similar to promises :)
- 0xmohit 11y ago"A few years" is a very long time for a relatively new and evolving language. Perhaps that is the reason that people have become more conscious of making _drastic_ changes -- rust and go are examples.
- lucaspiller 11y agoKind of related: One thing that has bit me a few times with promises is accidentally missing a return in the promise body. As such whatever called the promise just sits there forever, waiting for something that will never come. Is there a way in Bluebird to have it throw an exception or similar if the function executes without returning anything?
- spion 11y agoNormally bluebird should produce this warning when that happens: http://bluebirdjs.com/docs/warning-explanations.html#warning-a-promise-was-created-in-a-handler-but-none-were-returned-from-it http://bluebirdjs.com/docs/warning-explanations.html#warning... If it doesn't do that for your case then its likely that it needs some fixing - you should probably open an issue and we'll try to reproduce it... Also, thenlint might work for you: https://www.npmjs.com/package/thenlint https://www.npmjs.com/package/thenlint
- Touche 11y agoI sort of don't understand your problem. If you forget to return a value won't the thing consuming the Promise just get undefined as the value (and perhaps throws an exception expecting the value to be something other than undefined)?
- deleted 11y ago[deleted]