Catching errors based on Error.name

I was thinking that in many cases, it might be more convenient to use a String to catch errors rather than constructors, and the reason is that when it comes to modules, you actually need to export modules, making it much more cumbersome to type. Compare the following:

Promise.resolve(foo)
.then(() => { ... })
.catch(MyModule.errors.MyFirstError, err => { ... })
.catch(MyModule.errors.MySecondError, err => { ... })
...

vs:

Promise.resolve(foo)
.then(() => { ... })
.catch("MyFirstError", err => { ... })
.catch("MySecondError", err => { ... })
...

Where in the first catch err.name === "MyFirstError" and in the second catch err.name === "MySecondError".

[benjamingr]

Bluebird 3.0 supports something similar. Assuming you don’t want to alias and import the errors directly anyway:

  promise.catch({name: "MyFirstError"}, err => { ... }); // valid Bluebird 3

Thanks for the suggestion. https://github.com/petkaantonov/bluebird/issues/499

[perrin4869]

Well, the only problem I have with ES6 exports is that unfortunately, they do not yet work natively in node.js, even the newest 4.1.x versions, so they are not a viable solution yet.

OK, my very last pitch to supporting strings in catch clauses will be that there are times when constructors are just not available at all. For example, take socket.io. If, say, the client gives a callback to their emit to the server, and the server throws and error and wants to hand it to the client, the error gets serialized and sent back as json to the client… This is what I mean:

client.emitAsync('login', credentials)
.catch(err => err.name === 'RetryLoginError', err => { ... })

Of course this means that the client can’t have a constructor because the error they got is not an instance of Error, and it could never be. At that point, the only way to write multiple catch clauses is to use predicate functions, which work perfectly, but are more verbose than I would like.