Roll-out ValidationError to all modules

[mrgrain]

We have introduced a new error type ValidationError into aws-cdk-lib, seeerrors.ts.

This error type now needs to be rolled-out everywhere in aws-cdk-lib.
This will be a huge effort and significant grunt work. See tips below for how to make this easier.

Example PR: #33031

Here is the plan:

• As a team, split up the work between aws-cdk-lib and all alpha modules.
• Raise exactly 1 PR per module
• Do NOT make any other changes. If something isn't a straightforward update, park it for now.
• If something isn't a ValidationError, check you may use UnscopedValidationError but it's a last resort and should be avoided.
• Add the module to the list of checked modules in packages/aws-cdk-lib/.eslintrc.js.
• If you are completing an alpha module (not aws-cdk-lib) make sure to add the no-throw-default-error rule to the local eslint config.

We might have to ignore it in a few places that are still unclear.

Tips:

• Enforce using typed errors by adding the new module first into .eslintrc.js
• Once you have done that, eslint and VSCode should flag up all rule violations and changing errors will be semi-automatic and super easy.
• Consider using Amazon Q as well.

[athewsey]

I just tried to use ValidationError in an external library outside of core CDK, and errors doesn't seem to be exported by aws-cdk-lib. Is this expected?

If it's intended as a standard & general template for throwing validation errors in the context of a scope, then surely it'd be useful for authors of community constructs in e.g. CDKLabs too?

[mrgrain]

Hi @athewsey it should be possible to use ValidationError with the latest version. It is however only available in TS/JS and not from jsii-language apps. The intended use is mainly for reusable libraries, not apps you control yourself directly. The latter don't have as much of a problem w.r.t to identifying where an error is originating from.