Hacker News Reader

Comment by Illniyar | Hacker News Reader

Why the suggestion to use an error's name rather then instaneof and the error's class?

Error.prototype.toString() reads e.name, not e.prototype.constructor.name, so you can't rely on everyone to have subclassed Error.

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.

This is what I do when working with my own Error types.