-
Notifications
You must be signed in to change notification settings - Fork 26.3k
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
Conversation
585eb91
to
d2640b0
Compare
The commit message doesn't correctly reflect the changes, |
return new UnknownError(error); | ||
} | ||
|
||
export class UnknownError<T extends unknown> extends Error { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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})
As mentionned in #60273, can you also update the golden files with |
bb90864
to
6ce72e2
Compare
Done |
6ce72e2
to
85d9897
Compare
return new UnknownError(error); | ||
} | ||
|
||
export class UnknownError<T extends unknown> extends Error { |
There was a problem hiding this comment.
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.
e639981
to
aadad84
Compare
It used to return `unknown`. Now it's `Error | undefined`. For non-`Error` types they are encapsulated in new `UnknownError` class.
aadad84
to
5175a88
Compare
@@ -8,7 +8,7 @@ | |||
"experimentalDecorators": true, | |||
"emitDecoratorMetadata": true, | |||
"module": "esnext", | |||
"target": "es2020", | |||
"target": "es2022", |
There was a problem hiding this comment.
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: ...})/
Close in favour of #60610. |
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
It used to return
unknown
.Now it's
Error | undefined
.For non-
Error
types they are encapsulated in newUnknownError