new design of error handling

[raitucarp]

What about new design of error handling? I mean, I know that node.js is single threaded, but cmon.. every uncaughtexception error, or if there is throw new error, it's close entire application, hang and crash and bam!. Domain solution is not bad, but not clear enough and give some production headache.

Is new design of error handling possible?

sorry, if this is a duplicate issue

[ghostbar]

I use a combination of cluster with process.on('uncaughtException'..., very similar to what's expressed here http://shapeshed.com/uncaught-exceptions-in-node/

That makes your application behave like a phenix.

[rumkin]

@ghostbar This solution solves fail-safety problem. But not error handling.

[ghostbar]

@rumkin indeed, but error handling is solved on programming, not throwing errors but actually doing something with them. That's what I do at least. Very few times I have errors not being handled.

[benjamingr]

@raitucarp if you promisify your code you get error handling with propagation etc for free. So - in my opinion there is a user level solution to this problem.

[rlidwka]

if you promisify your code

Sure. If you explain how to promisify streams and other eventemitters.

Right now domains could be used to catch any kind of errors: async, throws, error event, anything. Promises can't replace all that.

[benjamingr]

Don't promisify streams and other event emitters - you can use the exact same idea though - wrap the callbacks in try/catch from the outside and propagate. It could be an interesting idea.

[ibc]

What about new design of error handling? I mean, I know that node.js is single threaded, but cmon.. every uncaughtexception error, or if there is throw new error, it's close entire application, hang and crash and bam!. Domain solution is not bad, but not clear enough and give some production headache.

Just code correctly and be ready for errors before they happen (I mean: use try&catch).

No magic here, and no magic in any language. If an error happens (and the code does not manage it) then memory leak or inconsistent state may happen. Don't make the language/platform responsible of fixing that.

[raitucarp]

@ibc you should read @tj medium https://medium.com/code-adventures/farewell-node-js-4ba9e7f3e52b

I believe, Io.js or node.js itself is not a language specification, error handling in platform may be redesigned

[tj]

It'll be somewhat mitigated when js-land is async/await & utilizes promises at the lowest level possible. Everything built on that would be inherently more fault tolerant.

In general it's always been sort of backwards in js-land, personally I think async is the exception not the rule, so Go and friends approach of blocking by default makes more sense and is much easier to work with.

If / when core uses promises all a lot of the madness could disappear. Someone posted a diagram of how streams work in node the other day, I think that illustrates how terrible evented programming is for non-trivial problems. The Go equiv would be muchhhh easier to grok because backpressure is implicitly applied by a lack of read, no awkward propagation. (This isn't unique to Go, just using it as an example).

I've heard some weird issues with promises as well, I haven't read into that much to be honest so I can't comment there.

Not sure what the plan is going forward, seemed like lots of people still dislike the idea of core being anything but callbacks, that's the direction I'd go though. Node is already so synonymous with "tiny core that does almost nothing" so that might be hard to break.

[bodokaiser]

@tj do you really think promises will fix this? I remember some bad times debugging errors inside duo, component or koa which lay deep inside some node modules.

[benjamingr]

@bodokaiser a promise implementation that's tuned towards error handling like bluebird does this a lot better than promise libraries like es6-promise since it does call stack stitching and proper error handling. Might want to check it out.