Introduktion till felhantering i Angular 7: Del 1 – Angular errorHandler

I den här handledningen får du en introduktion till fel i JavaScript, try-catch-konceptet och hur det används samt en liten introduktion till hantering av interna fel med Angular errorHandler.

Fel

En av mina favoritfilmstjärnor, Samuel L. Jackson, var den allra första person som jag hörde frasen ”to err is human” från, och även om jag inte kommer ihåg titeln på just den filmen så kan du nu hålla med mig om att samma sak händer med fel när du skriver kod. Som Angular-utvecklare vet du redan att fel kan orsakas av personliga misstag, som att ha en importförklaring med filtilläggsnamnet i Angular 7 och att det dyker upp i din webbläsare om du inte lyckas fånga upp det.

 import { DataService } from 'src/app/services/data.service.ts';

Fel kan uppstå på grund av bristande testning, serverkommunikation eller till och med tvetydighet i Angular-projektet du arbetar med. Vi är människor och därför är vi benägna att göra fel, det är en av anledningarna till att en bra editor som VS Code alltid kommer att rita pipiga linjer när du börjar spåra ur.

Förutsättningar

För att kunna följa med i den här artikelns demonstration bör du ha:

• Node version 11.0 installerad på din maskin.
• Node Package Manager version 6.7 (levereras vanligen med Node-installationen).
• Angular CLI version 7.0
• Den senaste versionen av Angular (version 7)

 // run the command in a terminal ng version

Bekräfta att du använder version 7, och uppdatera till 7 om du inte gör det.Andra saker som kommer att vara bra att ha är:

• En fungerande kunskap om Angular-ramverket på en nybörjarnivå.
• Förtroende med Angular-tjänster kommer att vara ett plus men inte ett krav.

Typer av fel

Det finns många typer av fel men jag kommer att gruppera dem i två huvudkategorier: insider- och outsiderfel.

• Insiderfel: (även kallat fel på klientsidan) Det är dessa som du kan hållas ansvarig för, syntaxfel, fel i pakethanteraren, referensfel, typfel och alla typer av fel på klientsidan som kan åtgärdas av utvecklaren i Angular-applikationen.
• Outsiderfel: (även kallat fel på serversidan) Dessa fel kan vara allt från serverfel, som oftast kommer med tresiffriga statuskoder som 500, till nätverksfel på Internet och till och med webbläsarspecifika fel. Dessa är i princip fel som ligger utanför Angular-applikationens räckvidd, därav namnet outsider.

Denna artikel kommer att fokusera på insider-felen och en efterföljande artikel kommer att fokusera på outsider-felen.

Baby steg: throw och catch!

När du kör en funktion i JavaScript, ansluter sig funktionen till en slags kö för funktionsutförande, och när applikationen körs och kommer till sin tur lämnar den kön och blir utförd. Så om ett fel uppstår kastar JavaScript ett undantag, vilket omedelbart tar bort alla operationer i kön tills undantaget hanteras. På en grundläggande nivå hanteras undantag med try/catch-block, hela programmet kraschar om kompilatorn inte ser detta try/catch-block. Syntaxen för try/catch ser ut så här:

Du kommer att se användbarheten i en liten demonstration. Skapa ett nytt Angular-projekt med CLI, kalla det ngapp

 ng new ngapp

Acceptera routerinställningarna och välj vanlig CSS som formatmall. Gå till filen app.component.ts och kopiera in koden nedan:

Kopiera dessa till app.component.html

 <!-- src/app/app.component.html --> <button (click)="normalError()"> Fire Normal Error </button>

Kopiera sedan denna grundläggande styling till app.component.css

Kör programmet i utveckling så här:

 ng serve

I vissa fall kommer det att misslyckas med att kompilera, när detta händer körs det om och det kommer att kompileras.

Detta visas i konsolen och för det mesta bryter hela applikationen omedelbart eftersom du kan se att meddelandet vi loggade inte visades. Try/catch-blocket hanterar dessa undantag på ett elegant sätt och programmet fortsätter att köras. Så om du hade en annan knapp med ett try catch block den här gången kan du upptäcka skillnaden. Kopiera detta i app.component.html file :

Kopiera koden nedan i app.component.ts-filen:

Koden i fetstil visar samma referensfelsinstans, men den här gången är den inlindad i ett try-catch-block så att den kan hanteras elegant. När du kör appen igen ska den se ut så här:

Begränsningar av try/catch

Och hur bra try/catch än är, när du tänker på applikationen ser du redan hur det inte är hållbart. Detta beror på att du inte kan gå och lägga till dessa try/catch-block i varje funktion i din applikation, det är inte resurseffektivt. Den goda nyheten är att Angular har ett slags global try/catch som vi kan använda på en centraliserad plats för att fånga upp alla undantag.

Felhanterare

Angular har en global felhanteringsklass som heter errorHandler som ger en krok för centraliserad undantagshantering i din applikation. Den fångar i princip upp alla fel som inträffar i din applikation och loggar dem alla till konsolen och hindrar appen från att krascha (det var därför som din första knapp inte kraschade appen).Syntaxen ser ut så här:

Detta gör att vi kan ändra standardbeteendet med att logga fel till konsolen till vår egen logik efter att vi har lagt till den i vår leverantörslista i vår appmodul. Gå till filen app.component.ts och kopiera koden nedan i den:

The try catch block has been removed, so you should have two squeaky lines (or problems) in your code editor signifying two reference errors. För att testa Angulars globala felhanterare navigerar du nu till filen app.module.ts och kopierar koden nedan:

Förändringarna gjordes precis som syntaxen antyder vi skapade en global felhanterarklass som implementerar Angulars felhanterare och registrerade den sedan i Provider-avsnittet Vår logik kontrollerar helt enkelt om det finns några fel och loggar ett meddelande för alla fel som hittas. Om du sparar detta och kör applikationen kommer du att se texterna som loggas i konsolen för varje fel och applikationen fungerar precis som om den var en try-catch.

Felttjänst

Nu kan du se att all vår fellogik är inne i core app-modulen, detta är inte det sätt Angular uppmuntrar oss att skriva kod på. Så i linje med att hålla allt modulärt använder vi en tjänst. du kommer att kalla den error service och all logik om hur du hanterar dina fel kommer att hållas i den. Först och främst genererar du en Angular-tjänst med CLI:

 ng generate service error

eller

 ng g s error

Därefter måste du ta bort felhanteringslogiken i din app.module.ts-fil så att den ser ut så här:

Efter det använder du CLI för att generera en felkomponent dit användaren kan omdirigeras om ett fel uppstår.

 ng g c error

Nu har du felkomponenten och behöver inte ändra den, navigera till error.service.ts-filen och kopiera koden nedan i den:

Här modifieras logiken lite så att den först kontrollerar vilken typ av fel det är, om det är ett insiderfel navigerar den användaren till en felsida när felet uppstår. Så se till att din app-routing.module.ts-fil uppdateras med rutten så här:

Slutligt bör din app.component.html-fil se ut så här:

Om du följde inlägget till den här punkten kan du köra programmet i utveckling igen, dina fel kommer att hanteras på ett elegant sätt som förväntat.

Slutsats

Du har introducerats till fel och konceptet bakom hanteringen av dem i Angular med klassen errorHandler med fokus på JavaScript-fel på klientsidan. Nästa handledning kommer att gå djupt in på outsiderfel, HTTP interceptors och felspårning med en fjärrtjänst som bygger på alla de begrepp du lärt dig i det här inlägget. Den fullständiga koden för den här handledningen finns på GitHub och kan hittas här.