This project adheres to the Contributor Covenant code of conduct. By participating, you are expected to uphold this code. Please report unacceptable behavior to [email protected].
@inrupt/solid-client-errors is a JavaScript library for handling RFC9457 Problem Details on HTTP error responses.
This feature is currently available in ESS. Servers implementing RFC9457 Problem Details will be supported too.
Our JavaScript Client Libraries use relatively modern JavaScript, aligned with the ES2020 Specification features, we ship both ESM and CommonJS, with type definitions for TypeScript alongside.
This means that out of the box, we only support environments (browsers or runtimes) that were released after mid-2020, if you wish to target other (older) environments, then you will need to cross-compile our SDKs via the use of Babel, webpack, SWC, or similar.
If you need support for Internet Explorer, it is recommended to pass them
through a tool like Babel, and to add polyfills for e.g.
Map, Set, Promise, Headers, Array.prototype.includes, Object.entries
and String.prototype.endsWith.
See Inrupt Solid Javascript Client Libraries.
For the latest stable version of solid-client-errors:
npm install @inrupt/solid-client-errorsIf you have questions about working with Solid or just want to share what you’re working on, visit the Solid forum. The Solid forum is a good place to meet the rest of the community.
- For public feedback, bug reports, and feature requests please file an issue via GitHub.
- For non-public feedback or support inquiries please use the Inrupt Service Desk.
Integrators of this library will generally use the following pattern to throw
a subclass of ClientHttpError, corresponding to the response status.
import { handleErrorResponse } from "@inrupt/solid-client-errors";
const response = await fetch(url, options);
if (response.status !== 200) {
const responseBody = await response.text();
throw handleErrorResponse(
response,
responseBody,
"application error message",
);
}The specific error type corresponds to the HTTP status code in the response, each of
which implements the WithProblemDetails type.
- 400:
BadRequestError - 401:
UnauthorizedError - 403:
ForbiddenError - 404:
NotFoundError - 405:
MethodNotAllowedError - 406:
NotAcceptableError - 409:
ConflictError - 410:
GoneError - 412:
PreconditionFailedError - 415:
UnsupportedMediaTypeError - 429:
TooManyRequestsError - 500:
InternalServerError
Each error includes a problemDetails field with the following properties:
type: URL: The specific error type. By default, this isabout:blank.title: string: A short description of the problem.status: number: The error response status code.detail?: string: A longer description of the problem.instance?: URL: A unique URL identifying the problem occurrence.
Consumers of these errors may handle the ProblemDetails data in the following way:
const res = await getFile(url, options)
.then((file) => { /* Do something after a successful request */ }
.catch((err) => {
if (hasProblemDetails(err)) {
const problems = err.problemDetails;
/* Do something with the details of the failed request */
} else {
/* Do something with a generic error message */
}
});See the release notes.