Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Error Handling in Node.js

joyent.com

Post reply on HN
Print view View original

11–20 of 96 posts

Re: Error Handling in Node.js

#11

Post by Illniyar »

hueving wrote: post #2

Giant post about the nightmare that is making robust code in node.js. Summary, don't use a language in large projects that makes it so easy to leak errors and exceptions. There's something to be said about the compiler forcing you to declare what exceptions your code can throw to force you to think about this stuff up front.

Not really, just normal error handling issues like most other languages.

You should always know how the api you are using returns an error and use it - most langauges have multiple common ways of notifying of an error.

As to leaking, coming from Java's terrible error handling, you just start using runtime errors all the time anyway, at least with js the result is more concise.

Re: Error Handling in Node.js

#12

Post by Illniyar »

prodigal_erik wrote: post #4

This isn't stuff every programmer should know, it only concerns people who are trying to write complex non-blocking Javascript without async/await (which are already implemented in Babel and proposed for ES7). It also focuses on Node-only idioms which IMHO should be deprecated in favor of ES6 Promises (which Node's LTS release supports natively!)

The title of the post is just "error handling in node.js".

Probably should change the submission title.

Re: Error Handling in Node.js

#14

Post by flukus »

latch wrote: post #8

My non-node specific suggestions: 1 - Don't catch errors unless you can actually handle them (and chances are, you can't handle them). Let them bubble up to a global handler, where you can have centralized logging. There's a fairly old discussion with Anders Hejlsberg that talks about this in the context of Java's miserable checked exception that I recommend [1]. This is also why, in my mind, Go gets it wrong. 2 - In…

> This is also why, in my mind, Go gets it wrong.

Considering the amount of places I see c# code catch errors and continue as though nothing happened I have to wonder how many wild go and c programmers simply ignore error codes?

Re: Error Handling in Node.js

#15

Post by prodigal_erik »

treve wrote: post #6
woodruffw wrote: post #3

The main conclusion I drew from this is that node.js has three "standard" ways to return/propagate an error, along with "traditional" methods (return code, global errno, etc). What's the deal? To someone who programs primarily in C and Ruby, this feels like a tremendous complication of the normal programming process.

Part of the problem in JS is that there's pretty much 2 classes of functions. Asynchronous functions and synchronous functions. Both are extremely common. Async/await solves this to some extent, because you can just go back to 1 way of error handling, which is throwing and catching exceptions. The third way (working with EventEmitter) is an odd pattern, but it's really more for specialized use-cases. Wouldn't really…

The trouble with "go foo()" is that it's fire-and-forget; foo's return value is literally discarded. When you need to know what happened (which should be nearly always), foo and every caller all have to opt-in to passing any result and/or error and/or panic value over a channel or something. It's one of many places where Go gives you tiny pieces of the right thing and makes you assemble them yourself.

Re: Error Handling in Node.js

#16

Post by btschaegg »

latch wrote: post #8

My non-node specific suggestions: 1 - Don't catch errors unless you can actually handle them (and chances are, you can't handle them). Let them bubble up to a global handler, where you can have centralized logging. There's a fairly old discussion with Anders Hejlsberg that talks about this in the context of Java's miserable checked exception that I recommend [1]. This is also why, in my mind, Go gets it wrong. 2 - In…

When it comes to 1.), a better way to state things is may be that you shouldn't ignore errors unless you were able to completely handle them.

Catching exceptions to throw exceptions with better messages is something I would stronly suggest, since almost no exceptions are useful without contextual information. I.e. which file was not found? The config, not the input or output. Things like this. This is especially useful in C++, where you don't get stack traces, but also in other languages you'll want to present non-technical (i.e. non-dev) users with meaningful messages. Stack traces will just frighten them off.

Your comment on sensitive information also plays into this.

I'll agree that just swallowing errors and going on is a recipe for disaster. This is something that regularly bugged me in most of the C code I've encountered so far.

Re: Error Handling in Node.js

#17

Post by kbart »

hueving wrote: post #2

Giant post about the nightmare that is making robust code in node.js. Summary, don't use a language in large projects that makes it so easy to leak errors and exceptions. There's something to be said about the compiler forcing you to declare what exceptions your code can throw to force you to think about this stuff up front.

What better alternatives do you know? I don't know any programming language for real world projects that would make error handling trivial.

Re: Error Handling in Node.js

#18

Post by wyager »

kbart wrote: post #17
hueving wrote: post #2

Giant post about the nightmare that is making robust code in node.js. Summary, don't use a language in large projects that makes it so easy to leak errors and exceptions. There's something to be said about the compiler forcing you to declare what exceptions your code can throw to force you to think about this stuff up front.

What better alternatives do you know? I don't know any programming language for real world projects that would make error handling trivial.

Trivial? No. But you can at least make it better than the horrible nightmare described in the OP. Monadic error handling in a strongly typed language gives you a huge leg up on safely and sanely managing the complexity of error handling, because it provides simple value-level error semantics and clear type-level indications of exactly what kinds of errors you have to deal with and how you have to deal with them.

Re: Error Handling in Node.js

#19

Post by wyager »

I'm not really sure how to phrase this constructively, but this is horrible. Not the article, just the fact that humans expose themselves to this sort of stuff. Why would you choose to use a language that makes something as mundane as error handling this ridiculous and unpleasant?

Re: Error Handling in Node.js

#20

Post by wyager »

latch wrote: post #8

My non-node specific suggestions: 1 - Don't catch errors unless you can actually handle them (and chances are, you can't handle them). Let them bubble up to a global handler, where you can have centralized logging. There's a fairly old discussion with Anders Hejlsberg that talks about this in the context of Java's miserable checked exception that I recommend [1]. This is also why, in my mind, Go gets it wrong. 2 - In…

Monad transformers offer a more disciplined and pleasant alternative to your #1. You should handle errors at the value level, not with some magic error passing system provided by your language. You can catch the errors at whatever level you like, and you are forced to deal with them properly by construction.
Post reply on HN