Maybaygiare.org

Blog Network

foutafhandeling in lange belofte ketens

de Tao van Beloften

met een beetje meer ervaring en begrip van beloften en de monadische wetten die het gebruik ervan regelen, zouden we niet zo veel tijd hebben besteed aan de refactor van dit stuk code.

in JavaScript kan asynchrone code worden afgehandeld via Promises, de vervolg monads van JavaScript. Het belangrijkste in dit geval over beloftes die een monad zijn, is dat de volgende wet waar is:

Promise.resolve(Promise.resolve(x)) === Promise.resolve(x).

en belangrijker dan de bovenstaande, deze geldt ook voor elke waarde x:

Promise.resolve(Promise.reject(x)) === Promise.reject(Promise.resolve(x)) === Promise.reject(x).

deze magische regel hierboven is wat me aan het eind van de dag wat gedachtekracht heeft bespaard. Dit betekende dat ik die fouten kon behandelen zodra ze gebeurden, binnen hun eigen functies, wegblijven van die lange keten waanzin. Het antwoord was er altijd, staarde naar me, ik kon het gewoon niet zien. Nu zie ik het, en het is prachtig.

Nu dat is een goede, ware Belofte

Dit betekende dat ik kon gewoon de saveApplication functie zoals dit bijvoorbeeld:

function saveApplication() {
return makeApiCall().catch((err) => Promise.reject('basic'));
}

Het .catch block betekent dat we omgaan met een fout op de basis stap van het formulier, omdat de saveapplication aanroep is gerelateerd aan de stap van het formulier genaamd basic. Dit leidde ons naar het mooie stukje code beneden:

saveApplication()
.then(uploadImages)
.then(saveService)
.then(savePricingInfo)
.then(savePaymentInfo)
.then(gotoMainPage)
.catch((step) => {
setErrorState();
multiStepManager.go(step);
});

we moesten slechts een enkele regel van de Promise chain wijzigen, nu alle functies binnen de .dan blocks geeft een belofte die al weigert om de bijbehorende stap.

maar wat als er andere soorten fouten optreden, die niet door de binnenste vangsten werden behandeld?

dat kan gemakkelijk worden opgelost door aangepaste fouttypen te implementeren en de evaluatie van verschillende fouttypen in onze hoofdpagina te scheiden .vang blok. Als volgt:

function saveApplication() {
return makeApiCall().catch((err) => Promise.reject(new StepError('basic')));
}//
saveApplication()
.then(uploadImages)
.then(saveService)
.then(savePricingInfo)
.then(savePaymentInfo)
.then(gotoMainPage)
.catch((step) => {
if(err instanceof StepError) {
setErrorState();
multiStepManager.go(step);
}
else {
// handle other types of errors
}
});

In dit geval, de main .catch block behandelt alleen fouten van het type StepError. Andere soorten fouten worden gewoon gegooid, niet afgewezen, zodat ze dienovereenkomstig kunnen worden behandeld door de toepassing of de browser.

hetzelfde principe kan en moet worden uitgebreid tot specifieke fouttypen, zoals verschillende HTTP-statussen.

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.