Throwing errors and good practices

[fpirsch]

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.

[youssef-saber-3]

Hey , we've updated error handling in the next beta version of the sdk ,as well as adding typescript support in this version. you can follow the guide here for setup and feel free to give feedback or report any issues you run into

[fpirsch]

22.3.1-rc3 still throws intances of custom Exception classes, not native Errors

[Reivilo85k]

Hi @fpirsch, could you give us some examples of such errors please ?

[fpirsch]

Hi @Reivilo85k I was referring to FailResponseException.js, NotFoundException.js, OAuthProviderException.js, UnauthorizedException.js

[Reivilo85k]

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.