Prokurilaj eraroj en Spring WebClient: reaga traktado kontraŭ protokolado
Distingi la reagan erarsignalon de WebClient, la transportan protokoladon kaj la traktadon de HTTP-statuso dum prokurila fiasko.
La transporto povas protokoli malsukcesan prokurilan konekton dum la aplikaĵo ankaŭ ricevas kaj traktas la reagan eraron. La protokola ero sola ne pruvas, ke la traktilo de la aplikaĵo estis preterlasita.
Sekvu la erarsignalon en la ĉeno, kiun oni efektive abonas. try/catch ĉirkaŭ kodo, kiu nur konstruas Mono, estas alia sfero ol trakti postan retan fiaskon.
| Operatoro | Efiko |
|---|---|
| doOnError | Plenumas flankan efikon dum la eraro daŭras |
| onErrorMap | Transformas eraron en alian eraron |
| onErrorResume | Ŝaltas al alternativa eldonanto |
Elektu la konduton, kiun la aplikaĵo bezonas. Registri metrikon ne postulas redoni falsan sukcesan enhavon. Alternativa respondo devus esti konscia rezulto de la aplikaĵo, ne maniero kaŝi fiaskan vojon.
Ankaŭ distingu transportajn esceptojn de ricevitaj HTTP-erarstatusoj. Prokurila konekto povas fiaski antaŭ ol ekzistas ordinara respondo de la celo, do HTTP-stata traktilo eble havas nenion por ekzameni. Konservu la kaŭzon de WebClientRequestException kiam oni diagnozas la pli malaltan fiaskon.
Ĝustigu protokoladon nur post kiam vi komprenas la rezulton. Malŝalti la tutan transportan protokolilon povas forigi pruvojn bezonatajn por posta tempolimo, TLS-problemo aŭ aŭtentiga fiasko, sen ŝanĝi la konduton de la reaga pipelino.