-
Notifications
You must be signed in to change notification settings - Fork 83
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
Throwing errors and good practices #502
Comments
22.3.1-rc3 still throws intances of custom Exception classes, not native |
Hi @fpirsch, could you give us some examples of such errors please ? |
Hi @Reivilo85k I was referring to |
Hi @fpirsch , Thank you for your feedback. After careful consideration, we've decided to retain our current approach to custom exceptions as it aligns with our design goals. We appreciate your understanding and continued support. |
The lib throws custom objects instead of
Error
objects, so we don't have the stack trace and logging can't be standardized.It is considered good practice to throw only instances of the Error class or its subclasses.
https://eslint.org/docs/latest/rules/no-throw-literal
https://rules.sonarsource.com/typescript/RSPEC-3696/
Custom exceptions should extend the native
Error
function.The text was updated successfully, but these errors were encountered: