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

81–90 of 96 posts

Re: Error Handling in Node.js

#81

Post by dozzie »

btschaegg wrote: post #16
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 usef…

> Catching exceptions to throw exceptions with better messages is something I would stronly suggest, since almost no exceptions are useful without contextual information.

Much more important is to wrap these exceptions generated in internal code in custom types. List of raised exceptions is a part of code's interface, and one shouldn't generally expose this kind of internal details as public API.

Re: Error Handling in Node.js

#82

Post by novaleaf »

Forcing the party line of callback hell as a high quality "Production Practice" 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.

Re: Error Handling in Node.js

#83

Post by Ntrails »

biztos wrote: post #74
Ntrails wrote: post #48

Earlier quoted context omitted.

Could you elaborate? Assuming that scary.MightNotWork() is some kind of ancillary function that is non-essential, why would I want to let it impact the main program. The example that comes to mind would be logging. If I have set up my own "Write logs into network share" call, I'd never ever expect it to throw errors that took down the app. Share down? Don't care. logfile locked/corrupt. Don't care. Try and log, if yo…

Sure. If your function does things internally that might return errors, the normal thing to do is have your function also potentially return an error, namely the first error it finds. If you call a function the error of which isn't a big deal to your function, you'd normally check the return value to make sure it meets your expectations. If it does, fine -- proceed accordingly. If it doesn't, then send the error up t…

> I would argue, a very bad habit in any language where the error could possibly be other than what you expect

Assuming that ModOrEpoch was being used to populate a mouseover somewhere on a ui that literally could not be less important, any error propagation is going to be degrading service considerably more than swallowing any error and returning epoch time.

Unless there is (and there could well be) a subset of errors which actually cause serious concerns but don't cause errors in any other function in the application? Do you have any examples/thoughts of what that might entail. :)

Re: Error Handling in Node.js

#84

Post by [deleted] »

cutler wrote: post #78

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's popular certainly doesn't seem to have any connection with engineering principles.

[deleted]

Re: Error Handling in Node.js

#85

Post by prodigal_erik »

Illniyar wrote: post #68
prodigal_erik wrote: post #45

Earlier quoted context omitted.

Error.prototype.toString() reads e.name, not e.prototype.constructor.name, so you can't rely on everyone to have subclassed Error. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

I'm not following, why can't I use: e instanceof Error or: e instanceof MyError why does toString() have anything to do with this?

It's very likely someone did

  const e = new Error('bad stuff happened')
  e.name = 'MyError'
without actually creating a MyError class to check with instanceof.

Re: Error Handling in Node.js

#86

Post by btschaegg »

dozzie wrote: post #81
btschaegg wrote: post #16

Earlier quoted context omitted.

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 usef…

> Catching exceptions to throw exceptions with better messages is something I would stronly suggest, since almost no exceptions are useful without contextual information. Much more important is to wrap these exceptions generated in internal code in custom types. List of raised exceptions is a part of code's interface, and one shouldn't generally expose this kind of internal details as public API.

If you're wrapping third party code that uses custom exception types, absolutely. However, regarding custom types, I found that you can get astonishingly far with most standard error types defined by many languages. So, if the internal code already uses those, I wouldn't see them as much of a problem - a FileNotFoundException essentially may as well stay one.

Of course, default exception types won't work if you have to convey more contextual information that is missing in the according interface. Also, using the same default exception type for different underlying errors can be problematic (an example for this would be C#'s AppSettingsReader.GetValue()[1] - it makes it impossible to distinguish between a parsing error or a missing key via the API).

[1]: https://msdn.microsoft.com/de-de/library/system.configuratio...

Re: Error Handling in Node.js

#87

Post by wyager »

jstimpfle wrote: post #47
wyager wrote: post #20

Earlier quoted context omitted.

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.

Are you talking about things like EitherT? IMO here isn't so much of a difference to exception handling. Both approaches make it hard to see at a glance where most code could fail, and you can (but are not encouraged to) transform errors explicitly. Add Java's checked exceptions, now the practical differences are quite subtle. Of course it's nice to be able to be able to do transformations with higher level functions…

You can manipulate value-level things like EitherT in ways that are not convenient or possible in Java.

EitherT and friends also force you to handle exceptions explicitly before getting a value out. In Java, you can usually just ignore it and "let it bubble up" as someone suggested earlier.

Re: Error Handling in Node.js

#88

Post by Illniyar »

prodigal_erik wrote: post #85
Illniyar wrote: post #68

Earlier quoted context omitted.

I'm not following, why can't I use: e instanceof Error or: e instanceof MyError why does toString() have anything to do with this?

It's very likely someone did const e = new Error('bad stuff happened') e.name = 'MyError' without actually creating a MyError class to check with instanceof.

Unless it's common in popular libraries/packages, I don't see why I need to take it into account.

Which popular libraries do this?

If it's just in a few places, it should be handled specifically, and use sane choices in other places.

Re: Error Handling in Node.js

#89

Post by Silhouette »

visionscaper wrote: post #57

This article promotes the fail-fast approach, something I very much dislike (against popular opinion it seems). I'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 NOT defensive coding. It is extremely dangerous to just dete…

FWIW, I wouldn't suggest the term "defensive coding" as the opposite to "fail fast". It's very similar to the established term "defensive programming", which IMHO is more about designing systems to make fewer assumptions. How you then handle a situation where you do detect that some expectation has not been met, including the fail-fast strategy, seems like a related but separate issue.

Terminology aside, though, I agree with much of what you say. The idea that it's generally acceptable for buggy code to just crash out seems to be making an unwelcome return recently, often among the same kinds of developers who don't like big design up front or formal software architecture because they want everything to be done incrementally and organically, and in the case of web apps specifically, often among developers who also consider code that runs for a year or two to be long-lived anyway.

Re: Error Handling in Node.js

#90

Post by Silhouette »

alkonaut wrote: post #42
Illniyar wrote: post #27

Earlier quoted context omitted.

There is nothing mundane about error handling, in fact it's one of the hardest things to get right in a programming language (see Rust's error handling saga for instance). There is no language I know of where error handling is both simple and not overbearing.

The most annoying thing about all this is that the central argument of this article "Separate recoverable errors from bugs" never made it to a widely used imperative language. C# had the opportunity but blew it. Java mixed the two kinds of exceptions up completely and checked exceptions just added insult to that injury. The best implementation I have seen for an imperative language is in Midori (The language used in…

That the blog post is indeed very interesting reading.
Post reply on HN