You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Before switching the codebase to use promises internally (e.g. #1541, #1603), we used callbacks with a typed error argument. This meant that the type system provided information to a caller of an asynchronous function about what type of error that function might emit. This information is useful since it allows the compiler to enforce a couple of things:
when internally needing to extract information from an emitted error, it made sure that we correctly internally handled the different types of error that we might expect to receive
it ensured that we stuck to the our public API contract, i.e. that the SDK only emits ErrorInfo errors
After switching to using promises, we've lost these guarantees, since there's no way in the TypeScript type system for a function to express that it throws errors of a specific type.
We should think about how to handle this, to try and get as close to the previous guarantees as we can.
The approach taken here is the same as that taken in 2001675, in order
to be able to emit both an error _and_ the response body.
Note that in the "just in case" handling of thrown errors I’ve just
typed the thrown error as `any` and not worried about the consequences
of doing so; we can figure out how to handle this properly and
consistently in #1617.
The approach taken here is the same as that taken in 2001675, in order
to be able to emit both an error _and_ the response body.
Note that in the "just in case" handling of thrown errors I’ve just
typed the thrown error as `any` and not worried about the consequences
of doing so; we can figure out how to handle this properly and
consistently in #1617.
The approach taken here is the same as that taken in 2001675, in order
to be able to emit both an error _and_ the response body.
Note that in the "just in case" handling of thrown errors I’ve just
typed the thrown error as `any` and not worried about the consequences
of doing so; we can figure out how to handle this properly and
consistently in #1617.
Before switching the codebase to use promises internally (e.g. #1541, #1603), we used callbacks with a typed
error
argument. This meant that the type system provided information to a caller of an asynchronous function about what type of error that function might emit. This information is useful since it allows the compiler to enforce a couple of things:ErrorInfo
errorsAfter switching to using promises, we've lost these guarantees, since there's no way in the TypeScript type system for a function to express that it
throw
s errors of a specific type.We should think about how to handle this, to try and get as close to the previous guarantees as we can.
┆Issue is synchronized with this Jira Task by Unito
The text was updated successfully, but these errors were encountered: