Whitelabel-felsidor ser trubbiga ut och kan påverka användarupplevelsen negativt. Lär dig hur du skapar anpassade felsidor med Thymeleaf.

Programvaran upplever fel. Även de bästa applikationerna kommer att stöta på fel vid något tillfälle. Därför bör varje applikation ha vissa felhanteringsmekanismer på plats.

Spring Boot tillhandahåller en standard Whitelabel-felsida som en komponent i dess automatiska konfiguration för felhantering. Icke desto mindre är förväntningarna att utvecklare kommer att skapa en anpassad felsida som ersätter Whitelabel-felsidan. I den här artikeln får du lära dig hur du anpassar felsidan för dina Spring Boot-applikationer.

Spring Boots Whitelabel-felsida

När en Spring Boot-applikation stöter på ett fel, begär den /error URL. Om det inte finns någon vy på den här platsen visar den Whitelabel-felsidan:

Whitelabel-felsidan anger datum och tid för felet, tillsammans med dess motsvarande tidszon. Dessutom indikerar den feltypen och dess tillhörande kod. Whitelabel-sidan säger det

instagram viewer
detta är ett 404-fel (sidan hittas inte). Detta beror på att exempelapplikationen inte har någon mappning för URL: en "/produkter".

Det mesta av informationen som presenteras på Whitelabel-felsidan är hämtad från specifika felattribut. Spring Boots felvy har tillgång till följande felattribut:

  • fel: orsaken till felet.
  • tidsstämpel: datum och tid då felet inträffade.
  • status: felstatuskoden.
  • undantag: klassnamnet på rotundantaget (om felet är ett resultat av ett undantag).
  • meddelande: undantagsmeddelandet (om felet är ett resultat av ett undantag).
  • fel: Alla resultat från ett BindingResult-undantag (om felet är ett resultat av ett undantag).
  • spår: undantagsstackspårningen (om felet är ett resultat av ett undantag).
  • väg: URL-sökvägen där felet uppstår.

Skapa en felsida med Thymeleaf

Din Spring Boot-applikation bör ha en enda felsida lagrad i en "fel"-mall. Förlängningen av denna mall kommer att variera beroende på vilken mallteknik du väljer att använda. Om du till exempel väljer en Java Server Pages-mall (JSP) ska filnamnet vara error.jsp.

Detta exempel på Spring Boot-applikationen använder dock mallmotorn för Thymeleaf. Så, mallens namn är error.html. Du bör konsekvent placera din felmall i mall mapp, under Resurser katalog med alla dina andra mallfiler.

Filen error.html

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 anpassade felsidan utför flera viktiga uppgifter. Den förklarar förekomsten av ett fel. Därefter visar det upp HTTP-förfrågan som utlöste felet. Dessutom förser den användaren med statuskoden som är associerad med felet. Men om användaren inte är bekant med statuskoder, förklarar sidan också innebörden av koden genom felattributet.

Den sista textraden ger användaren ett meddelande i händelse av ett undantag. Sedan tillåter länken i slutet användaren att navigera tillbaka till startsidan. De error.html filen använder en CSS-stilmall och två bilder för att skapa följande vy:

Håll din felsida användarvänlig

Det primära syftet med felsidan är att informera användaren om att ett specifikt fel har inträffat. Den här felsidan är dock fortfarande en aspekt av applikationen. Därför är det avgörande att se till att felsidan också är användarvänlig.

Detta innebär att du väljer att använda felattributen som kommunicerar felet på ett mer okomplicerat sätt. Så du kan välja att använda sökvägsattributet istället för spårningsattributet, som är mycket mer komplext och innehåller detaljer som användaren inte behöver känna till.

Du vill inte heller ge en slumpmässig användare överdriven information om din applikations inre funktion, eftersom detta kan äventyra applikationens säkerhet.