Maybaygiare.org

Blog Network

felhantering i långa Löfteskedjor

Tao Of Promises

med lite mer erfarenhet och förståelse av löften och de monadiska lagarna som styr dess användning, skulle vi inte ha spenderat så mycket tid på att arbeta med refactor av denna kod.

i JavaScript kan asynkron kod hanteras via löften, som är Fortsättningsmonaderna för JavaScript. Det viktigaste i det här fallet om löften är en monad är att följande lag är sant:

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

och viktigare än den ovan, den här gäller också för något värde x:

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

denna magiska regel ovan är det som räddade mig lite tankekraft i slutet av dagen. Detta innebar att jag kunde behandla dessa fel så snart de hände, inuti sina egna funktioner, hålla sig borta från den långa kedjan galenskap. Svaret var alltid där och stirrade på mig, jag kunde bara inte se det. Nu ser jag, och det är vackert.

nu är det en bra, Sant löfte

detta innebar att jag helt enkelt kunde ha saveapplication-funktionen så här, till exempel:

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

den .catch block innebär att vi hanterar ett fel på det grundläggande steget i formuläret, eftersom saveApplication-samtalet är relaterat till steget i formuläret som heter basic. Detta ledde oss till den vackra bit kod nedanför:

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

vi hade bara att ändra en enda rad i löftet kedjan, nu när alla funktioner inuti .sedan returnerar block ett löfte som redan avvisar till motsvarande steg.

men vad händer om andra typer av fel inträffade, som inte hanterades av de inre fångsterna?

Tja, det kan enkelt lösas genom att implementera anpassade feltyper och separera utvärderingen av olika feltyper i vår Huvud .fånga block. Så här:

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
}
});

i det här fallet är huvudet .catch block hanterar endast fel av typen StepError. Andra typer av fel kastas helt enkelt, inte avvisas, så att de kan hanteras i enlighet med applikationen eller webbläsaren.

samma princip kan och bör utökas för att hantera specifika feltyper, till exempel olika HTTP-statuser.

Lämna ett svar

Din e-postadress kommer inte publiceras.