Documentation on error handling using instanceof vs. name property

[vobarian]

Describe the issue

I am seeing conflicting advice, and would like clarification.

In this repo, ERROR_HANDLING.md, under "Handling service returned errors" [1]:

you can use switches to handle errors based on the error name. instanceof checks are not recommended for error handling due to the possibility of prototype mismatch caused by nesting or other forms of copying/duplication.

But in this AWS Blog, it is all about how we can now use instanceof and implies this is preferable. [2]

In the version 3.53.0 of the modular AWS SDK for JavaScript (v3), we introduced concrete classes for AWS service exceptions which support asserting service exceptions with instanceof operator. In this post, we cover how to use it and how it improves the error handling experience.

Links

[1]
https://github.com/aws/aws-sdk-js-v3/blob/main/supplemental-docs/ERROR_HANDLING.md#handling-service-returned-errors
[2]
https://aws.amazon.com/blogs/developer/service-error-handling-modular-aws-sdk-js/

[kuhe]

We primarily recommend using error.name string field for determining the error type.

instanceof works under ideal conditions and was recommended earlier in the life of the project. We discovered later that prototype mismatch is a common enough and hard-to-explain case that it was better to use error.name overall.

Rather than deprecating the instanceof advice, we later added a [Symbol.hasInstance] override to our base error class so that you can continue to use instanceof checks. With the latest version of the SDK clients, you should be able to use error.name and instanceof interchangeably.

• todo: update our documentation to explain this.

[github-actions]

This issue has not received a response in 1 week. If you still think there is a problem, please leave a comment to avoid the issue from automatically closing.

[github-actions]

This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one.