Error Handling in Node.js

My non-node specific suggestions:<p>1 - Don&#x27;t catch errors unless you can actually handle them (and chances are, you can&#x27;t handle them). Let them bubble up to a global handler, where you can have centralized logging. There&#x27;s a fairly old discussion with Anders Hejlsberg that talks about this in the context of Java&#x27;s miserable checked exception that I recommend [1]. This is also why, in my mind, Go gets it wrong.<p>2 - In the context of error handling (and system quality), logging and monitoring are the most important thing you can do. Period. Only log actionable items, else you&#x27;ll start to ignore your logs. Make sure your errors come accompanied by a date (this can be done in your central error handler, or at ingestion time (via logstash or what have you)<p>3 - Display generic&#x2F;canned errors to users...errors can contain sensitive information.<p>4 - Turn errors you run into and fix into test cases.<p>[1] - <a href="http:&#x2F;&#x2F;www.artima.com&#x2F;intv&#x2F;handcuffs.html" rel="nofollow">http:&#x2F;&#x2F;www.artima.com&#x2F;intv&#x2F;handcuffs.html</a>

Giant post about the nightmare that is making robust code in node.js. Summary, don&#x27;t use a language in large projects that makes it so easy to leak errors and exceptions. There&#x27;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.

For me, error handling has a major flaw: stack unwinding - extremely annoying thing to happen when the program state took many many hours to achieve. I don&#x27;t think there is any language other than CL that allows restarts etc. to be defined; slime-repl too is invaluable when debugging.<p><a href="http:&#x2F;&#x2F;www.gigamonkeys.com&#x2F;book&#x2F;beyond-exception-handling-conditions-and-restarts.html" rel="nofollow">http:&#x2F;&#x2F;www.gigamonkeys.com&#x2F;book&#x2F;beyond-exception-handling-co...</a>

Some of this looks like horrible advice, particularly the defeatist attitude towards what the article calls &quot;programmer errors&quot;. Statements to the effect that you can never anticipate or handle a logic error sensibly so the only thing you should ever do is crash immediately are hard to take seriously in 2016. What about auto-saving recovery data first? Logging diagnostic information? Restarting essential services in embedded systems with limited interactivity? This article basically dismisses decades of lessons learned in defensive programming with an argument about as sophisticated as &quot;It&#x27;s too hard, we should all just give up&quot;.<p>As others have already mentioned, much of the rest is quite specific to Node&#x2F;JS, and many of the issues raised there could alternatively be solved by simply choosing a better programming language and tools. The degree to which JS has overcomplicated some of these issues is mind-boggling.

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

Why the suggestion to use an error&#x27;s name rather then instaneof and the error&#x27;s class?

It beats me why Node.js is anywhere near as popular as Elixir if real concurrency and error handling are a priority. Is programming just a fashion industry? What&#x27;s popular certainly doesn&#x27;t seem to have any connection with engineering principles.

If you&#x27;re going to check every argument&#x27;s type and throw on failure, either use a statically typed language or adopt a concise way of type checking. Many of the examples have big groups of assert() calls at the top. Gross.

Can anyone explain why this pattern doesn&#x27;t work? Or point me to some resource?<p><pre><code> function myApiFunc(callback) { &#x2F;* * This pattern does NOT work! *&#x2F; try { doSomeAsynchronousOperation(function (err) { if (err) throw (err); &#x2F;* continue as normal *&#x2F; }); } catch (ex) { callback(ex); } }</code></pre>

Forcing the party line of callback hell as a high quality &quot;Production Practice&quot; is an incredible disservice by not introducing the user to the concept of Promises. It already assumes a basic knowledge of exception handling, so at least they should hint at what is a saner choice.

I&#x27;m surprised such an in-depth article doesn&#x27;t even mention promises. Upcoming async&#x2F;await (already available via transpilation) will make error handling in Node sane again.

This article promotes the fail-fast approach, something I very much dislike (against popular opinion it seems).<p>I&#x27;m very much in favor of the opposite approach, defensive coding. Often when I read opinion pieces about how bad defensive coding is, they almost always seem to forget that defensive coding without proper logging, error-handling and monitoring is <i>NOT</i> defensive coding. It is extremely dangerous to just detect error conditions without any feedback: you have no idea what is going on in your system!<p>IMHO properly applied defensive coding, works as follows:<p>* Detect inconsistent situations (e.g. in a method, expected an object as input argument, but got a null)<p>* Log this as an error and provides feedback to the caller of the method that the operation failed (e.g. through an error callback).<p>* The caller can then do anything to recover, (e.g. reset a state, or move to some sort of error state, close a file or connection, etc.).<p>* The caller should then also provide feedback to its caller, etc. etc.<p>This programming methodology gives the following advantages:<p>* You are made to think about the different problems that can occur and how you should recover them (or not)<p>* Highly semantic feedback about what is going wrong when an issue occurs; this makes it very easy to pinpoint issues and fix them<p>* Server application keeps on running to handle other requests, or can be gracefully shut down.<p>* Client side application UIs don’t break, user is kept in the loop about what is happening<p>Of course you will need to keep a safety net to catch uncaught exceptions, properly logging and monitoring them (and restart your application if relevant)<p>The fail-fast approach, as I have seen it applied, doesn’t do any checking or mitigation, with the effect that:<p>- you are thrown out of you normal execution path, losing a lot of context to do any mitigation (close a file, close a connection, tell a caller something went wrong)<p>- you only get a stack trace from which it can be hard to figure out what went wrong<p>- there can be big impact on user experience : UIs can stop working, servers that stop responding (for <i>all</i> users).<p>I have very good experiences with using the defensive coding paradigm, but it takes more work to do it right; for many, especially in the communities that use dynamic typing, such as the JS community, this seems to be a too big a hurdle to take. This is unfortunate because it IMO it could greatly improve software quality.<p>Any feedback is welcome!<p>(Edit: formatting to improve readability) (Edit: clarified defensive coding as an opposite approach to fail-fast)

On error goto...

This isn&#x27;t stuff <i>every programmer</i> should know, it only concerns people who are trying to write complex non-blocking Javascript without async&#x2F;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&#x27;s LTS release supports natively!)

This is a joke

I&#x27;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?