Skip to content

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

Closed
Humberd wants to merge 1 commit into
angular:mainfrom
Humberd:resource-typed-error
Closed

Humberd wants to merge 1 commit into
angular:mainfrom
Humberd:resource-typed-error

Conversation

@Humberd

@Humberd Humberd commented Mar 7, 2025

Copy link
Copy Markdown
Member

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
Copy Markdown
Member

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

Comment thread packages/core/src/resource/resource.ts Outdated

@JeanMeche JeanMeche Mar 7, 2025

Copy link
Copy Markdown
Member

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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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

Humberd commented Mar 14, 2025

Copy link
Copy Markdown
Member Author

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
Comment thread packages/core/src/resource/resource.ts Outdated

Copy link
Copy Markdown
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
Copy Markdown
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
Comment thread packages/tsconfig.json
"emitDecoratorMetadata": true,
"module": "esnext",
"target": "es2020",
"target": "es2022",

@Humberd Humberd Mar 21, 2025

Copy link
Copy Markdown
Member Author

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

Humberd commented Mar 28, 2025

Copy link
Copy Markdown
Member Author

Close in favour of #60610.

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

Copy link
Copy Markdown

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