Programvare kan oppleve uventede problemer. Selv de mest robuste applikasjonene vil uunngåelig støte på feil. Derfor er det viktig at alle applikasjoner har robuste mekanismer for feilhåndtering.
Spring Boot tilbyr en standard «Whitelabel»-feilside som en del av sin automatiske feilhåndteringskonfigurasjon. Likevel er det vanlig praksis at utviklere lager egendefinerte feilsider for å erstatte denne standardvisningen. Denne artikkelen vil demonstrere hvordan du kan tilpasse feilsiden i dine Spring Boot-applikasjoner.
Spring Boots standard feilside (Whitelabel)
Når en Spring Boot-applikasjon genererer en feil, forsøker den å aksessere URL-en «/error». Hvis ingen spesifikk visning er konfigurert for dette endepunktet, presenteres «Whitelabel»-feilsiden:
Denne siden viser tidspunktet for feilen, inkludert tidssone, i tillegg til feiltype og tilhørende kode. I dette tilfellet indikerer den en 404-feil (Siden finnes ikke), siden eksempelapplikasjonen ikke har en tilordning for URL-en «/produkter».
Informasjonen som vises på Whitelabel-feilsiden, er hentet fra spesifikke feilattributter. Spring Boots feilvisning har tilgang til følgende attributter:
- error: Beskrivelsen av feilen.
- tidsstempel: Dato og tidspunkt for feilen.
- status: HTTP-statuskoden for feilen.
- unntak: Navnet på klassen som representerer unntaket (hvis feilen skyldes et unntak).
- melding: Meldingen fra unntaket (hvis feilen skyldes et unntak).
- feil: Resultater fra et BindingResult-unntak (hvis feilen skyldes et unntak).
- trace: Stack trace for unntaket (hvis feilen skyldes et unntak).
- bane: URL-banen der feilen oppstod.
Opprett en egendefinert feilside med Thymeleaf
I en Spring Boot-applikasjon bør du ha en dedikert feilside lagret i en mal med navnet «error». Filendelsen vil avhenge av malmotoren du bruker. For eksempel, hvis du velger JSP, vil filnavnet være «error.jsp».
I dette eksemplet bruker vi imidlertid Thymeleaf som malmotor, så filnavnet er «error.html». Det er vanlig å lagre feilmalen i den samme mappen som andre malfiler, vanligvis under ressurskatalogen.
Filen error.html
<!DOCTYPE html>
<html xmlns:th="http://www.thymeleaf.org">
<head>
<title>Error</title>
<link rel="stylesheet" th:href="https://wilku.top/how-to-create-custom-spring-boot-error-pages-with-thymeleaf/@{/css/style.css}"/>
</head>
<body th:style="'background: url(/images/background1.jpg) no-repeat center center fixed;'">
<div class="container" >
<h1>En feil har oppstått...</h1>
<img th:src="https://wilku.top/how-to-create-custom-spring-boot-error-pages-with-thymeleaf/@{/images/error-icon.png}" width="100px" height="100px" />
<p>Det ser ut til å være et problem med siden du ba om (<span th:text="${path}"></span>).</p>
<p th:text="${'Statuskoden er ' + status + ', som betyr at siden ble ' + error + '.'}"></p>
<p th:text="${'Ytterligere detaljer: ' + message + '.'}"></p>
<a class="btn" href="https://wilku.top/home">Tilbake til hjem</a>
</div>
</body>
</html>
Den egendefinerte feilsiden utfører flere viktige funksjoner. Den informerer brukeren om at en feil har oppstått. Den viser deretter den spesifikke HTTP-forespørselen som forårsaket feilen. I tillegg presenterer den statuskoden knyttet til feilen. For brukere som ikke er kjent med statuskoder, gir siden også en forklaring av koden gjennom feilattributtet.
Den siste tekstlinjen gir brukeren en feilmelding hvis et unntak oppsto. Til slutt gir en lenke brukeren mulighet til å navigere tilbake til hjemmesiden. Filen «error.html» bruker et CSS-stilark og to bilder for å generere følgende visning:
Lag en brukervennlig feilside
Det overordnede formålet med en feilside er å informere brukeren om at en feil har oppstått. Men en feilside er fortsatt en del av applikasjonen din, og det er derfor viktig at den også er brukervennlig.
Dette innebærer å velge feilattributter som formidler feilen på en lettfattelig måte. Du bør for eksempel velge å bruke «path»-attributtet i stedet for «trace»-attributtet, som er mye mer komplekst og inneholder detaljer som brukeren ikke trenger å se.
Du bør også unngå å presentere tilfeldige brukere med overdreven informasjon om applikasjonens interne funksjoner, da dette kan kompromittere sikkerheten.