Typed Errors for aws-cdk-lib et. al. [Tracking] #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
mergify bot
pushed a commit
that referenced
this issue
Dec 7, 2024
### Issue # (if applicable) Relates to #32324 ### Reason for this change Currently all errors are untyped. This makes it difficult users to programmatically distinguish between different classes of errors, e.g. what is a validation error vs what is a syntax error? With this change, users can catch errors and check their type before proceeding accordingly. ### Description of changes Addition of a new Error type `ValidationError`. For now this error is used only in a single file. The intention is to extend this to all error cases. `ValidationError` extends an abstract `ConstructError` which also handles any improvements to error display. `ConstructError` manipulates the stack trace to improve display. It's changing two things, both of which are based on a construct that is passed in on error creation. If not construct is passed, the error behaves as before. 1. Construct information is inserted as the first line of the stack trace. 2. The strack trace is captured from the point of _creation of the construct_. That is the class constructor call. This is achieved by passing the error's constructs into [Error.captureStackTrace](https://nodejs.org/docs/latest-v22.x/api/errors.html#errorcapturestacktracetargetobject-constructoropt). As a side effect, in many cases the "line of error" is not minified code anymore and thus doesn't ruin the error experience for users. See comments for current vs future errors. ### Description of how you validated changes Existing test. Manual testing of error cases. ### 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*
mrgrain
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Tracking issue: Can be closed once we have migrated all errors and have enabled the eslint-rule to enforce typed errors.
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: