Whitelabel-virhesivut näyttävät tylsiltä ja voivat vaikuttaa negatiivisesti käyttökokemukseen. Opi luomaan mukautettuja virhesivuja Thymeleafin avulla.

Ohjelmistossa ilmenee virheitä. Jopa parhaat sovellukset kohtaavat virheitä jossain vaiheessa. Siksi jokaisessa sovelluksessa tulisi olla joitakin virheenkäsittelymekanismeja.

Spring Boot tarjoaa oletusarvoisen Whitelabel-virhesivun osana sen automaattista konfigurointia virheiden käsittelyä varten. Siitä huolimatta on odotettavissa, että kehittäjät luovat mukautetun virhesivun, joka korvaa Whitelabel-virhesivun. Tässä artikkelissa opit mukauttamaan virhesivua Spring Boot -sovelluksille.

Spring Bootin Whitelabel-virhesivu

Kun Spring Boot -sovellus kohtaa virheen, se pyytää /error URL-osoite. Jos tässä paikassa ei ole näkymää, se näyttää Whitelabel-virhesivun:

Whitelabel-virhesivulla näkyy virheen päivämäärä ja kellonaika sekä sitä vastaava aikavyöhyke. Lisäksi se osoittaa virhetyypin ja siihen liittyvän koodin. Whitelabel-sivulla sanotaan näin

instagram viewer
tämä on 404-virhe (Sivua ei löydetty). Tämä johtuu siitä, että esimerkkisovelluksessa ei ole kartoitusta /products-URL-osoitteelle.

Suurin osa Whitelabel-virhesivulla esitetyistä tiedoista on otettu tietyistä virhemääritteistä. Spring Bootin virhenäkymässä on pääsy seuraaviin virhemääritteisiin:

  • virhe: virheen syy.
  • aikaleima: päivämäärä ja kellonaika, jolloin virhe ilmenee.
  • Tila: virheen tilakoodi.
  • poikkeus: juuripoikkeuksen luokan nimi (jos virhe johtuu poikkeuksesta).
  • viesti: poikkeusviesti (jos virhe johtuu poikkeuksesta).
  • virheitä: Kaikki tulokset BindingResult-poikkeuksesta (jos virhe johtuu poikkeuksesta).
  • jäljittää: poikkeuspinon jäljitys (jos virhe johtuu poikkeuksesta).
  • polku: URL-osoite, jossa virhe tapahtuu.

Virhesivun luominen Thymeleafin avulla

Spring Boot -sovelluksessasi pitäisi olla yksi virhesivu, joka on tallennettu "error"-malliin. Tämän mallin laajennus vaihtelee käyttämäsi mallitekniikan mukaan. Jos esimerkiksi valitset Java Server Pages (JSP) -mallin, tiedostonimen tulee olla error.jsp.

Tämä esimerkki Spring Boot -sovelluksesta kuitenkin käyttää Thymeleaf-mallimoottori. Joten mallin nimi on error.html. Sinun tulee jatkuvasti sijoittaa virhemallisi sapluuna -kansion alla resursseja hakemistoon kaikkien muiden mallitiedostojesi kanssa.

Error.html-tiedosto

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>

Mukautettu virhesivu suorittaa useita tärkeitä tehtäviä. Se ilmoittaa virheen esiintymisestä. Myöhemmin se esittelee HTTP-pyyntö joka laukaisi virheen. Lisäksi se toimittaa käyttäjälle virheeseen liittyvän tilakoodin. Mutta jos käyttäjä ei tunne tilakoodeja, sivulla selitetään myös koodin merkitys error-attribuutin kautta.

Viimeinen tekstirivi antaa käyttäjälle viestin poikkeuksen sattuessa. Sitten lopussa oleva linkki sallii käyttäjän navigoida takaisin kotisivulle. The error.html tiedosto käyttää CSS-tyylitaulukkoa ja kahta kuvaa seuraavan näkymän luomiseen:

Pidä virhesivusi käyttäjäystävällisenä

Virhesivun ensisijainen tarkoitus on ilmoittaa käyttäjälle tietystä virheestä. Tämä virhesivu on kuitenkin edelleen osa sovellusta. Siksi on erittäin tärkeää varmistaa, että virhesivu on myös käyttäjäystävällinen.

Tämä tarkoittaa virhemääritteiden käyttöä, jotka viestivät virheestä mutkattomalla tavalla. Joten voit käyttää path-attribuuttia trace-attribuutin sijaan, koska se on paljon monimutkaisempi ja sisältää yksityiskohtia, joita käyttäjän ei tarvitse tietää.

Et myöskään halua antaa satunnaiselle käyttäjälle liikaa tietoja sovelluksesi sisäisestä toiminnasta, koska tämä saattaa vaarantaa sovelluksen turvallisuuden.