Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Decide how to handle typed errors after switching to promises #1617

Open
lawrence-forooghian opened this issue Feb 8, 2024 · 1 comment
Open

Decide how to handle typed errors after switching to promises #1617

lawrence-forooghian opened this issue Feb 8, 2024 · 1 comment
Labels
code-quality Affects the developer experience when working in our codebase.

Comments

@lawrence-forooghian
Copy link
Collaborator

lawrence-forooghian commented Feb 8, 2024 •
edited by sync-by-unito bot

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.

┆Issue is synchronized with this Jira Task by Unito
@lawrence-forooghian lawrence-forooghian added the code-quality Affects the developer experience when working in our codebase. label Feb 8, 2024
@sync-by-unito Sync by Unito
Copy link

sync-by-unito bot commented Feb 8, 2024

➤ Automation for Jira commented:

The link to the corresponding Jira issue is https://ably.atlassian.net/browse/SDK-4082

lawrence-forooghian added a commit that referenced this issue Feb 8, 2024
@lawrence-forooghian
Convert IPlatformHttp.doUri to use promises
1d9df7c 
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.
lawrence-forooghian added a commit that referenced this issue Feb 9, 2024
@lawrence-forooghian
Convert IPlatformHttp.doUri to use promises
d35ad62 
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.
lawrence-forooghian added a commit that referenced this issue Feb 15, 2024
@lawrence-forooghian
Convert IPlatformHttp.doUri to use promises
6f00409 
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
code-quality Affects the developer experience when working in our codebase.
Milestone
No milestone
Development

No branches or pull requests
1 participant
@lawrence-forooghian