Typed Errors for aws-cdk-lib et. al. #32324
Assignees
Comments
This was referenced Nov 28, 2024
mrgrain
added a commit
that referenced
this issue
Nov 29, 2024
### Reason for this change As part of #32324 we are enforcing stricter rules on thrown errors. ### Description of changes Enforce the `no-throw-literal` eslint rule. Fix the one instance that wasn't compliant yet. ### Description of how you validated changes Manual testing. Only changed code is in supporting CLI tool. ### Checklist - [x] My code adheres to the [CONTRIBUTING GUIDE](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and [DESIGN GUIDELINES](https://github.com/aws/aws-cdk/blob/main/docs/DESIGN_GUIDELINES.md) ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
github-actions bot
pushed a commit
to cdklabs/eslint-rules
that referenced
this issue
Nov 29, 2024
A new rule to enforce using custom error types instead of the default error object. <img width="802" alt="image" src="https://github.com/user-attachments/assets/b5e09529-7123-491a-af4c-942c5394e5d3"> Related to aws/aws-cdk#32324
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently all errors thrown by the AWS CDK in
aws-cdk-libetc are regular untypedErrors. That makes it difficult for a caller to distinguish between errors thrown intentionally by the construct library, and other errors like coding bugs etc.The CDK should only throw well typed errors.
All errors should be categorized into the type of error they are (most are going to be validation errors).
We should enforce this by writing an eslint rule.
Subtasks
The text was updated successfully, but these errors were encountered: