Thanks to visit codestin.com
Credit goes to github.com

Skip to content

refactor(core): narrow error type for resources API #60272

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

Humberd
Copy link
Member

@Humberd Humberd commented Mar 7, 2025

It used to return unknown.
Now it's Error | undefined.

For non-Error types they are encapsulated in new UnknownError

@pullapprove pullapprove bot requested a review from mmalerba March 7, 2025 14:16
@angular-robot angular-robot bot added the area: core Issues related to the framework runtime label Mar 7, 2025
@ngbot ngbot bot added this to the Backlog milestone Mar 7, 2025
@Humberd Humberd force-pushed the resource-typed-error branch 2 times, most recently from 585eb91 to d2640b0 Compare March 7, 2025 15:47
@JeanMeche
Copy link
Member

The commit message doesn't correctly reflect the changes, unknown should be undefined.

return new UnknownError(error);
}

export class UnknownError<T extends unknown> extends Error {
Copy link
Member

@JeanMeche JeanMeche Mar 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't we instead change ResourceStreamItem to {value: T} | {error: Error}; ?

This way we wouldn't have to add an additional symbol to our public API.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought about it. The question is do we want to allow the user pass non-Error values as errors.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My take: we should accept Error only, but we should also not have UnknownError.

It turns out ES2022 added new Error(message, {cause: ...}), which browsers and devtools understand and print along with the error. We should do that instead of subclassing.

Unfortunately Angular doesn't seem to opt into ES2022 typings yet, so we'd have to spell it as throw new (Error as any)('Unknown error', {cause: ...}) which is reasonable for now.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I updated ResourceStreamItem to {value: T} | {error: Error}.

Additionally:
If any caught error is of type Error we set error() signal to it.
Otherwise it is wrapped in Error('Unknown error', {cause: err})

@JeanMeche
Copy link
Member

As mentionned in #60273, can you also update the golden files with yarn bazel run //packages/core:core_api.accept. Thank you.

@Humberd Humberd force-pushed the resource-typed-error branch 3 times, most recently from bb90864 to 6ce72e2 Compare March 14, 2025 12:14
@Humberd
Copy link
Member Author

Humberd commented Mar 14, 2025

As mentionned in #60273, can you also update the golden files with yarn bazel run //packages/core:core_api.accept. Thank you.

Done

@mmalerba mmalerba requested review from alxhub and removed request for mmalerba March 18, 2025 03:40
@Humberd Humberd force-pushed the resource-typed-error branch from 6ce72e2 to 85d9897 Compare March 18, 2025 12:15
return new UnknownError(error);
}

export class UnknownError<T extends unknown> extends Error {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My take: we should accept Error only, but we should also not have UnknownError.

It turns out ES2022 added new Error(message, {cause: ...}), which browsers and devtools understand and print along with the error. We should do that instead of subclassing.

Unfortunately Angular doesn't seem to opt into ES2022 typings yet, so we'd have to spell it as throw new (Error as any)('Unknown error', {cause: ...}) which is reasonable for now.

@JeanMeche
Copy link
Member

@Humberd @alxhub We can actually add "es2022" to the lib entry in packages/tsconfig.json. #60066 actually did it to the build tsconfig.

@Humberd Humberd force-pushed the resource-typed-error branch 5 times, most recently from e639981 to aadad84 Compare March 21, 2025 14:18
It used to return `unknown`.
Now it's `Error | undefined`.

For non-`Error` types they are encapsulated in new `UnknownError` class.
@Humberd Humberd force-pushed the resource-typed-error branch from aadad84 to 5175a88 Compare March 21, 2025 14:19
@@ -8,7 +8,7 @@
"experimentalDecorators": true,
"emitDecoratorMetadata": true,
"module": "esnext",
"target": "es2020",
"target": "es2022",
Copy link
Member Author

@Humberd Humberd Mar 21, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tsconfig-build.json was changed in packages/core/test/resource/resource_spec.ts, but not tsconfig.json. Without it the IDE signals errors when using `Error(..., {cause: ...})/

@Humberd
Copy link
Member Author

Humberd commented Mar 28, 2025

Close in favour of #60610.

@Humberd Humberd closed this Mar 28, 2025
@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Apr 28, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area: core Issues related to the framework runtime
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants