Whitelabel-feilsider ser sløve ut og kan påvirke brukeropplevelsen negativt. Lær hvordan du lager egendefinerte feilsider ved hjelp av Thymeleaf.

Programvare opplever feil. Selv de beste applikasjonene vil støte på feil på et tidspunkt. Derfor bør hver applikasjon ha noen feilhåndteringsmekanismer på plass.

Spring Boot gir en standard Whitelabel-feilside som en komponent i den automatiske konfigurasjonen for feilhåndtering. Ikke desto mindre er forventningen at utviklere vil lage en egendefinert feilside som erstatter Whitelabel-feilsiden. I denne artikkelen lærer du hvordan du tilpasser feilsiden for Spring Boot-applikasjonene dine.

Spring Boots Whitelabel-feilside

Når en Spring Boot-applikasjon støter på en feil, ber den om /error URL. Hvis det ikke er noen visning på dette stedet, viser den Whitelabel-feilsiden:

Whitelabel-feilsiden angir dato og klokkeslett for feilen, sammen med dens tilsvarende tidssone. I tillegg indikerer den feiltypen og den tilhørende koden. Whitelabel-siden sier det

instagram viewer
dette er en 404 feil (side ikke funnet). Dette er fordi eksempelapplikasjonen ikke har noen tilordning for "/produkter"-URLen.

Mesteparten av informasjonen som presenteres på Whitelabel-feilsiden er hentet fra spesifikke feilattributter. Spring Boots feilvisning har tilgang til følgende feilattributter:

  • feil: årsaken til feilen.
  • tidsstempel: datoen og klokkeslettet da feilen oppstår.
  • status: feilstatuskoden.
  • unntak: klassenavnet til rotunntaket (hvis feilen er et resultat av et unntak).
  • beskjed: unntaksmeldingen (hvis feilen er et resultat av et unntak).
  • feil: Alle resultater fra et BindingResult-unntak (hvis feilen er et resultat av et unntak).
  • spore: unntaksstabelsporingen (hvis feilen er et resultat av et unntak).
  • sti: URL-banen der feilen oppstår.

Opprette en feilside med Thymeleaf

Spring Boot-applikasjonen din skal ha en enkelt feilside lagret i en "feil"-mal. Utvidelsen av denne malen vil variere avhengig av malteknologien du velger å bruke. For eksempel, hvis du velger en Java Server Pages (JSP)-mal, bør filnavnet være error.jsp.

Imidlertid bruker dette eksempelet Spring Boot-applikasjonen Thymeleaf-malmotoren. Så malnavnet er error.html. Du bør konsekvent plassere feilmalen i mal mappen under ressurser katalog med alle andre malfiler.

error.html-filen

html>
<htmlxmlns: th="http://www.thymeleaf.org">
 <head>
<title> Errortitle>
<linkrel="stylesheet"th: href="@{/css/style.css}"/>
 head>
 <bodyth: style="'background: url(/images/background1.jpg) 
 no-repeat center center fixed;'">
<divclass="container" >
<h1>An error has occurred...h1>
<imgth: src="@{/images/error-icon.png}"
 width="100px" height="100px" />
<p>There seems to be a problem with the page you requested 
 (<spanth: text="${path}">span>).p>
<pth: text="${'The status code is ' + status 
 + ', which means that the page was ' + error + '.'}">p>
<pth: text="${'Further details: ' + message + '.'}">p>
<aclass="btn"href="/home">Back to homea>
div>
 body>
html>

Den tilpassede feilsiden utfører flere viktige oppgaver. Den erklærer forekomsten av en feil. Deretter viser den frem HTTP-forespørselen som utløste feilen. Videre gir den brukeren statuskoden knyttet til feilen. Men hvis brukeren ikke er kjent med statuskoder, forklarer siden også betydningen av koden gjennom feilattributtet.

Den siste tekstlinjen presenterer brukeren med en melding i tilfelle unntak. Deretter tillater lenken på slutten brukeren å navigere tilbake til hjemmesiden. De error.html filen bruker et CSS-stilark og to bilder for å lage følgende visning:

Hold feilsiden din brukervennlig

Det primære formålet med feilsiden er å informere brukeren om at en spesifikk feil har oppstått. Denne feilsiden er imidlertid fortsatt et aspekt av applikasjonen. Derfor er det avgjørende å sikre at feilsiden også er brukervennlig.

Dette vil bety å velge å bruke feilattributtene som kommuniserer feilen på en mer ukomplisert måte. Så du kan velge å bruke path-attributtet i stedet for trace-attributtet, som er mye mer komplekst og inneholder detaljer som brukeren ikke trenger å vite.

Du vil heller ikke gi en tilfeldig bruker overdreven informasjon om den indre funksjonen til applikasjonen din, da dette kan kompromittere applikasjonens sikkerhet.