SDK-3306: Error class hierarchy #186
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This introduces the core classes for this library, namely: - `InruptClientError`, the superclass for all Inrupt client related errors, - `ClientHttpError`, the base class for HTTP errors Note that classes for specific HTTP errors (Unauthenticated, Not Found...) are not included yet, and will be added later. `ClientHttpError` extends the base `InruptClientError` by implementing two interfaces, `WithProblemDetails` and `WithErrorResponse`, respectively associated to their type guards `hasProblemDetails` and `hasErrorResponse`. Both the `.problemDetails` and `.response` accessors are marked as read-only, and immutability is enforced at runtime for libraries not using static analysis based on TS. The constructor of `ClientHttpError` takes in a response body and a subset of the native `Response` metadata, instead of taking a simple `Response` instance, because reading the `Response` body is an asynchronous operation, which isn't possible when building an object. It is expected that the parsing will be done by the caller in an async context, and the result will be passed to the `ClientHttpError` constructor, which is not the initial design. For the time being, I'm not doing any submodule exports (e.g. `@inrupt/solid-client-error/http`), but this is something we might eventually consider for tree-shaking.
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
acoburn
reviewed
Jul 1, 2024
| /** | ||
| * Superclass of all errors thrown by Inrupt's client libraries. | ||
| * | ||
| * @since unreleased |
There was a problem hiding this comment.
Is it typical to use unreleased in this context? I am only wondering about the possibility of forgetting to set this to the right version before release.
There was a problem hiding this comment.
That's the approach we have taken with our other libraries, so that it's easier to search for on release. However, we also have in other places a checklist item specifically for this, which was missing here: a250e37.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This introduces the core classes for this library, namely:
InruptClientError, the superclass for all Inrupt client related errors,ClientHttpError, the base class for HTTP errorsNote that classes for specific HTTP errors (Unauthenticated, Not Found...) are not included yet, and will be added later.
ClientHttpErrorextends the baseInruptClientErrorby implementing two interfaces,WithProblemDetailsandWithErrorResponse, respectively associated to their type guardshasProblemDetailsandhasErrorResponse. Both the.problemDetailsand.responseaccessors are marked as read-only, and immutability is enforced at runtime for libraries not using static analysis based on TS.The constructor of
ClientHttpErrortakes in a response body and a subset of the nativeResponsemetadata, instead of taking a simpleResponseinstance, because reading theResponsebody is an asynchronous operation, which isn't possible when building an object. It is expected that the parsing will be done by the caller in an async context, and the result will be passed to theClientHttpErrorconstructor, which is not the initial design.For the time being, I'm not doing any submodule exports (e.g.
@inrupt/solid-client-error/http), but this is something we might eventually consider for tree-shaking.This PR fixes bug #.
New feature description
Checklist
index.ts, if applicable.@sinceand@example)..tsfiles) are listed in theexportsfield inpackage.json, if applicable..tsfiles) are listed in thetypedocOptions.entryPointsfield intsconfig.json, if applicable.This PR bumps the version to .
Release Steps
npm version -- <major|minor|patch> --no-pushwith the decided on version (to prevent the tag from being pushed).CHANGELOG.mdto release the latest the version, and set the release date.release/vX.Y.ZbranchCHANGELOG.mdand the automatically generated changes.The release should have a new tag matching the new version number:
vx.y.z, and point to the release commit.