Strony błędów Whitelabel wyglądają tępo i mogą mieć negatywny wpływ na wygodę użytkownika. Dowiedz się, jak tworzyć niestandardowe strony błędów za pomocą Thymeleaf.

W oprogramowaniu występują błędy. Nawet najlepsze aplikacje w pewnym momencie napotkają błędy. Dlatego każda aplikacja powinna posiadać pewne mechanizmy obsługi błędów.

Spring Boot udostępnia domyślną stronę błędów Whitelabel jako element swojej automatycznej konfiguracji w celu obsługi błędów. Niemniej jednak oczekuje się, że programiści utworzą niestandardową stronę błędu, która zastąpi stronę błędu Whitelabel. W tym artykule dowiesz się, jak dostosować stronę błędów dla aplikacji Spring Boot.

Strona błędu Whitelabel Spring Boot

Gdy aplikacja Spring Boot napotka błąd, żąda /error Adres URL. Jeśli w tej lokalizacji nie ma widoku, wyświetli się strona błędu Whitelabel:

Strona błędu Whitelabel zawiera datę i godzinę wystąpienia błędu wraz z odpowiadającą mu strefą czasową. Dodatkowo wskazuje typ błędu i powiązany z nim kod. Strona Whitelabel tak stwierdza

instagram viewer
to jest błąd 404 (Strona nie znaleziona). Dzieje się tak, ponieważ przykładowa aplikacja nie ma mapowania adresu URL „/products”.

Większość informacji prezentowanych na stronie błędu Whitelabel pochodzi z określonych atrybutów błędów. Widok błędów Spring Boot ma dostęp do następujących atrybutów błędów:

  • błąd: przyczyna błędu.
  • znak czasu: data i godzina wystąpienia błędu.
  • status: kod stanu błędu.
  • wyjątek: nazwa klasy wyjątku głównego (jeśli błąd jest wynikiem wyjątku).
  • wiadomość: komunikat o wyjątku (jeśli błąd jest wynikiem wyjątku).
  • błędy: Wszelkie wyniki wyjątku BindingResult (jeśli błąd jest wynikiem wyjątku).
  • namierzać: ślad stosu wyjątków (jeśli błąd jest wynikiem wyjątku).
  • ścieżka: Ścieżka URL, w której występuje błąd.

Tworzenie strony błędu za pomocą Thymeleaf

Twoja aplikacja Spring Boot powinna mieć pojedynczą stronę błędu zapisaną w szablonie „błędu”. Rozszerzenie tego szablonu będzie się różnić w zależności od technologii szablonu, którą zdecydujesz się zastosować. Na przykład, jeśli wybierzesz szablon Java Server Pages (JSP), nazwa pliku powinna brzmieć błąd.jsp.

Jednak ta przykładowa aplikacja Spring Boot używa silnik szablonów Thymeleaf. Zatem nazwa szablonu to błąd.html. Powinieneś konsekwentnie umieszczać szablon błędu w pliku szablon folderze, pod zasoby katalog ze wszystkimi innymi plikami szablonów.

Plik 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>

Dostosowana strona błędów spełnia kilka ważnych zadań. Deklaruje wystąpienie błędu. Następnie prezentuje żądanie HTTP co spowodowało błąd. Ponadto dostarcza użytkownikowi kod stanu powiązany z błędem. Jeśli jednak użytkownik nie jest zaznajomiony z kodami stanu, strona wyjaśnia również znaczenie kodu poprzez atrybut błędu.

Ostatnia linia tekstu przedstawia użytkownikowi komunikat w przypadku wyjątku. Następnie link na końcu umożliwia użytkownikowi powrót do strony głównej. The błąd.html plik wykorzystuje arkusz stylów CSS i dwa obrazy, aby utworzyć następujący widok:

Dbaj o to, aby Twoja strona błędów była przyjazna dla użytkownika

Podstawowym celem strony błędu jest poinformowanie użytkownika o wystąpieniu określonego błędu. Jednak ta strona błędu nadal stanowi aspekt aplikacji. Dlatego kluczowe jest zapewnienie, że strona błędu jest również przyjazna dla użytkownika.

Będzie to oznaczać wybór atrybutów błędu, które komunikują błąd w bardziej nieskomplikowany sposób. Możesz więc zdecydować się na użycie atrybutu path zamiast atrybutu śledzenia, który jest znacznie bardziej złożony i zawiera szczegóły, o których użytkownik nie musi wiedzieć.

Nie chcesz także udostępniać przypadkowemu użytkownikowi nadmiernych informacji na temat wewnętrznego działania aplikacji, ponieważ może to zagrozić bezpieczeństwu aplikacji.