Repository navigation
new design of error handling #92
Description
Activity
I use a combination of
clusterwithprocess.on('uncaughtException'..., very similar to what's expressed here http://shapeshed.com/uncaught-exceptions-in-node/That makes your application behave like a phenix.
@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.
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.
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.
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.
@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
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.
@tj do you really think promises will fix this? I remember some bad times debugging errors inside
duo,componentorkoawhich lay deep inside some node modules.@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.
A lot of this could be solved by clearer more obvious error messages (giving a better idea of the component, which made it and why).
Then better documentation/ lookup references to these errors to give insight into developers who don't have deep knowledge of the core internals how they can mitigate the issue.
i'm -1 to any error "solution" in core. i've been using promises/generators for a while and rarely have uncaught exceptions. i'd rather have core remain minimal and let es7 async/await solve this for us.
and let es7 async/await solve this for us
We don't really want to wait 20.5 years for it to be implemented in V8 properly without command-line flags... do we?
It's more like 2 years for v8 to implement without flags and 5 years for node to update v8
I think that current js and nodejs error problem based on pure error object design which cause wick error notifications and unfair error capturing and throwing policy. There is a lot of libraries which throws deeply nested errors caused by wrong argument type of highlevel calls and a tones of malformed error objects like native nodejs ECONNRESET and so. Some libs use arrays to pass multiple errors and some use Native Object as a error report. The first step should be done in this direction.
@rumkin things like
ECONNRESETare actually being thrown in the correct place and the error type/name is more of a posix thing than an io.js specific thing. It is actually the socket connection, which has thrown the error. The problem often is how to figure out what is affected by that error, and how best to mitigate that in the code affected by it.Since it is thrown asynchronously there is only a short stack trace back to
net.js, this makes it much more difficult to deal withWhat I believe @jonathanong was eluding to, is that if you code with the premise of handling errors and are aware of what they are, when they could occur and how best to deal with them in your program/application. Whether these are handled them via language features (e.g. generators and promises) or just by handling the
errorevents these can be handled accordingly.TCP, FileSystem or other system errors just need to be understood by the developers using them, which is why I think more resources are needed to aid in educating and understanding these issues and how best to deal with them (obviously there is not always a one size fits all solution).
With regards to libraries throwing errors or using arrays of multiple errors, I think both of these things are anti-patterns and not really useful. Although new language features make it easier to deal with things, ideally the only times an error should be thrown is if one occurs and there is no handle on an
errorevent or there is a developer code/syntax error (which I think should always throw, to prompt a code change to fix the bug). Unfortunately there is no nice way to force module developers to adopt good error construction/handling principles so personally I would just avoid these modules as best I can.I think that the gist of this discussion has been that a solution in core is a no-go and that errors shouldn't be handled by the system, rather the developer. With the seemingly decreasing interest, I'll be closing this issue, but feel free to re-open it or open a new issue if you feel like it wasn't fully discussed.
Also, there is now error documentation! 😃
Ok thanks @brendanashworth I still watch this issue for updates 👍
- added a commit that references this issue
on Dec 7, 2015
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