-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Strategy for name
property given uglification?
#31
Comments
The short answerI hadn't really considered this. I originally built this library with the only intention of using it in Bluebird's This isn't ideal, but if you're using uglifyjs2, there are a few options available that might solve this for you quickly:
The long answerI've given a some thought to this library lately. I consider it to be a hack, and I'm not really a fan of hacks. Given the number of ways that it can break or fail to work as intended (uglifying, use with typescript, issues with different module bundlers, cross-environment issues, changes to babel, etc.), I would almost recommend not using it. A much simpler pattern that involves zero hacks could look something like this:
This should still capture the correct stack trace and message, while preserving the error name. You could also create other decorator functions to add additional info/properties to the error. |
Added a link to this issue in the readme. Closing for now. |
Given that name is determined via
this.constructor.name
, if one were to minify their code and mangle the names, this could lead tonew MyCustomError().name === 'e'
.The text was updated successfully, but these errors were encountered: