[Q] Since SyntaxError is also built-in, how do you usually handle that?

[erapoport]

I fully expect that as soon as I start using this library, someone will get confused between SyntaxError and errors.SyntaxError.

I just wrote this test and it doesn't pass:

 expect(err).to.be.an.instanceOf(errors.SyntaxError);

It does pass if I say instanceOf(SyntaxError). How can I globally overwrite the default one to keep the code sanity?

Thank you!

[David Fenster]

The standard error classes are re-included in common-errors in order to allow you to append stack traces

new errors.SyntaxError("no exclamation point allowed", someOtherError)

If you ever want to know if something is a SyntaxError, use instanceof(SyntaxError) with the global class as it will work for both.

I was a little wary of replacing the standard error classes with common-errors globally because of unintended side-effects. If that works for you, feel free to do so.

[erapoport]

instanceOf(SyntaxError) would work for both if I pass the original SyntaxError error?

 //bluebird typed error catcher
 .catch(SyntaxError, (e) => throw new errors.SyntaxError(no exclamation point allowed", e))

Have I read that correctly?

[David Fenster]

Yep!

If that does not work I consider it to be a bug that I will patch asap. I have tests that tell me it works, but do please let me know if you find differently.

[erapoport]

Wonderful, it was indeed my mistake and now both types pass the test. Now that part is working, but err.toString()seems to contain only the message from when I rethrow the error, not them both glued together as I expected.

EDIT: Actually, I'm not sure if that should be the default behavior. On the one hand, I don't want to glue the error message every time I convert from built-in errors, on the other hand, I should really have to minimize the occurrences where that's even needed. Hmm...