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.
Spis treści:
Strona błędu Whitelabel Spring Boot
Gdy aplikacja Spring Boot napotka błąd, żąda adresu URL /error. 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 stwierdza, że jest to błąd 404 (nie znaleziono strony). 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.
- timestamp: 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).
- komunikat: 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).
- trace: ś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ć error.jsp.
Jednak ta przykładowa aplikacja Spring Boot korzysta z silnika szablonów Thymeleaf. Zatem nazwa szablonu to error.html. Powinieneś konsekwentnie umieszczać szablon błędu w folderze szablonów, w katalogu zasobów ze wszystkimi innymi plikami szablonów.
Plik 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>An error has occurred...</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>There seems to be a problem with the page you requested
(<span th:text="${path}"></span>).</p>
<p th:text="${'The status code is ' + status
+ ', which means that the page was ' + error + '.'}"></p>
<p th:text="${'Further details: ' + message + '.'}"></p>
<a class="btn" href="https://wilku.top/home">Back to home</a>
</div>
</body>
</html>
Dostosowana strona błędów spełnia kilka ważnych zadań. Deklaruje wystąpienie błędu. Następnie prezentuje żądanie HTTP, które 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 za pomocą atrybutu 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. Plik error.html 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 o wewnętrznym funkcjonowaniu aplikacji, ponieważ może to zagrozić bezpieczeństwu aplikacji.