mirror of
https://github.com/angular/angular
synced 2026-05-24 09:28:37 +00:00
8ef5cc680d
**Unit Testing Code Does Not Compile** The compilation error is: ``` The compilation error is ./src/testing/http-client.spec.ts - Error: Module build failed (from ./node_modules/@ngtools/webpack/src/ivy/index.js): Error: /home/projects/obk3vc--run/src/testing/http-client.spec.ts is missing from the TypeScript compilation. Please make sure it is in your tsconfig via the 'files' or 'include' property. ``` I’m not sure what to say about unit testing HTTP in a full Standalone app. Is it different? _This is the only known remaining defect in this conversion of HTTP to Standalone._ **Edited content of `http-request-data-from-server.md`** The current version of this page is confusing. In particular * It tells readers they **should always unsubscribe** from the HttpClient method calls. This is *not true* and this example doesn't even do it. I replaced this instruction with more nuanced advice and an explanation of why it is OK to not unsubscribe to HttpClient methods. * There is a "helpful" note about using the RxJS `map` operator to transform the response. This is *not "helpfulf"*. It is *confusing* because the sample doesn't use `map` anywhere. It was unnecessary here, even if it might be helpful elsewhere. I removed this note. * The "Requesting a typed response" section seemed unclear to me, particularly because the guide begins with a `get` request that already has the `Config` return type specification. My revision attempts to make this more clear. * The bold "callout" about the `observe` and `responseType` options appears out of nowhere after "Requesting a typed response". It's disconcerting at best. I moved it to the bottom of the page and linked to it from the `options` discussion at the top. I made a few other revisions that I hope improve the readability of this page. **Corrected `http-make-jsonp-request.md`** The JSONP example, handwritten in the guide page, would not have compiled. I added one that does to `heroes.service.ts` and displayed it on this page. **Corrected `http-handle-request-errors.md` This page ended with a section called "Sending data to a server" that introduces PUT, POST, and DELETE. These features have nothing to do with error handling and the verbiage here duplicates the opening paragraphs of the next topic which does: "Send data to a server". So I deleted this section from the error handling guide page. **Archived http-setup-server-communication.md** `http-setup-server-communication.md` appears to be the original long document that has since been divided over the other pages in this folder. It shouldn’t be in the reader’s flow. I did update it for Standalone. But I also removed it from left-nav and marked as archived. PR Close #51400
53 lines
2.8 KiB
Markdown
53 lines
2.8 KiB
Markdown
# HTTP client - Handle request errors
|
|
|
|
If the request fails on the server, `HttpClient` returns an _error_ object instead of a successful response.
|
|
|
|
The same service that performs your server transactions should also perform error inspection, interpretation, and resolution.
|
|
|
|
When an error occurs, you can obtain details of what failed to inform your user.
|
|
In some cases, you might also automatically [retry the request](#retry).
|
|
|
|
<a id="error-details"></a>
|
|
|
|
## Getting error details
|
|
|
|
An app should give the user useful feedback when data access fails.
|
|
A raw error object is not particularly useful as feedback.
|
|
In addition to detecting that an error has occurred, you need to get error details and use those details to compose a user-friendly response.
|
|
|
|
Two types of errors can occur.
|
|
|
|
- The server backend might reject the request, returning an HTTP response with a status code such as 404 or 500.
|
|
These are error _responses_.
|
|
|
|
- Something could go wrong on the client-side such as a network error that prevents the request from completing successfully or an exception thrown in an RxJS operator.
|
|
These errors have `status` set to `0` and the `error` property contains a `ProgressEvent` object, whose `type` might provide further information.
|
|
|
|
`HttpClient` captures both kinds of errors in its `HttpErrorResponse`.
|
|
Inspect that response to identify the error's cause.
|
|
|
|
The following example defines an error handler in the previously defined ConfigService.
|
|
|
|
<code-example header="app/config/config.service.ts (handleError)" path="http/src/app/config/config.service.ts" region="handleError"></code-example>
|
|
|
|
The handler returns an RxJS `ErrorObservable` with a user-friendly error message.
|
|
The following code updates the `getConfig()` method, using a [pipe](guide/pipes-overview 'Pipes guide') to send all observables returned by the `HttpClient.get()` call to the error handler.
|
|
|
|
<code-example header="app/config/config.service.ts (getConfig v.3 with error handler)" path="http/src/app/config/config.service.ts" region="getConfig_3"></code-example>
|
|
|
|
<a id="retry"></a>
|
|
|
|
## Retrying a failed request
|
|
|
|
Sometimes the error is transient and goes away automatically if you try again.
|
|
For example, network interruptions are common in mobile scenarios, and trying again can produce a successful result.
|
|
|
|
The [RxJS library](guide/rx-library) offers several _retry_ operators.
|
|
For example, the `retry()` operator automatically re-subscribes to a failed `Observable` a specified number of times.
|
|
_Re-subscribing_ to the result of an `HttpClient` method call has the effect of reissuing the HTTP request.
|
|
|
|
The following example shows how to pipe a failed request to the `retry()` operator before passing it to the error handler.
|
|
|
|
<code-example header="app/config/config.service.ts (getConfig with retry)" path="http/src/app/config/config.service.ts" region="getConfig"></code-example>
|
|
|
|
@reviewed 2023-08-29
|