ERROR_SEVERITY()

ERROR_SEVERITY() to funkcja Transact-SQL zwracająca poziom istotności ostatnio wystąpionego błędu.

ERROR_SEVERITY() jako informacja o wadze błędu

ERROR_SEVERITY() jest funkcją języka Transact-SQL używaną do odczytania poziomu istotności błędu, który został przechwycony w bieżącym kontekście obsługi wyjątków. Zwracana wartość pomaga określić, czy problem dotyczy pojedynczego polecenia, całej procedury, połączenia z bazą danych, czy działania instancji SQL Server. Nie jest to opis błędu ani kod wskazujący jego przyczynę. Funkcja dostarcza jedynie liczbową informację o tym, jak poważnie środowisko traktuje dane zdarzenie.

Najczęściej ERROR_SEVERITY() stosuje się wewnątrz bloku TRY...CATCH. Po wystąpieniu błędu wykonanie przechodzi do części CATCH, w której można odczytać kilka właściwości bieżącego wyjątku. ERROR_MESSAGE() zwraca komunikat tekstowy, ERROR_NUMBER() numer błędu, ERROR_LINE() numer wiersza, ERROR_PROCEDURE() nazwę procedury, a ERROR_STATE() dodatkowy stan błędu. ERROR_SEVERITY() uzupełnia ten zestaw o poziom istotności, dzięki czemu rejestrowane zdarzenie jest bardziej przydatne podczas analizy.

Wartość funkcji ma charakter kontekstowy. Odczytana w odpowiednim miejscu bloku CATCH opisuje błąd, który spowodował wejście do tej sekcji. Poza kontekstem obsługi błędu nie należy zakładać, że funkcja zwróci dane dotyczące wcześniejszego zdarzenia. W praktyce oznacza to konieczność pobrania potrzebnych właściwości podczas obsługi wyjątku i zapisania ich w logu, tabeli diagnostycznej albo komunikacie przekazywanym do warstwy aplikacji.

ERROR_SEVERITY() w kontekście klasyfikacji błędów

Poziom istotności jest jednym z elementów wewnętrznej klasyfikacji błędów. Niskie poziomy mogą wskazywać ostrzeżenia albo problemy ograniczone do konkretnej instrukcji. Wyższe poziomy oznaczają sytuacje, które mogą przerwać wykonywanie bieżącego zadania, ograniczyć działanie sesji lub wpłynąć na szerszy zakres zasobów. Sama wartość nie powinna jednak być interpretowana bez komunikatu błędu, numeru błędu oraz informacji o tym, w jakiej operacji wystąpił problem.

Nie należy utożsamiać ERROR_SEVERITY() z pilnością zgłoszenia widzianą z perspektywy użytkownika. Błąd o umiarkowanym poziomie może być krytyczny dla określonego procesu biznesowego, jeżeli pojawia się podczas zapisu zamówienia lub rozliczenia. Z kolei zdarzenie o wyższym poziomie może być obsłużone automatycznie, jeżeli dotyczy kontrolowanego przerwania operacji i nie powoduje utraty danych. Ocena wpływu powinna łączyć poziom istotności z miejscem wystąpienia, częstotliwością oraz skutkiem dla aplikacji.

Warto również odróżnić ERROR_SEVERITY() od mechanizmów raportowania błędów. Funkcja nie zapisuje zdarzenia, nie wysyła powiadomienia i nie naprawia przyczyny problemu. Może natomiast zasilić procedurę, która zapisuje szczegóły do dziennika. Na tej podstawie można później filtrować przypadki wymagające reakcji, oddzielać błędy możliwe do ponowienia od tych, które wymagają analizy konfiguracji lub kodu, oraz zachować spójny format informacji diagnostycznych.

Znaczenie poziomu zależy także od rodzaju operacji. Błąd składni, naruszenie ograniczenia integralności, problem z uprawnieniami oraz przerwanie połączenia mogą mieć różne poziomy, mimo że dla użytkownika każdy z nich objawia się nieudaną czynnością. Dlatego poprawne porównanie wymaga sprawdzenia pełnego zestawu właściwości zwróconych w bloku CATCH, a nie tylko liczby uzyskanej przez ERROR_SEVERITY().

ERROR_SEVERITY() a typowe problemy diagnostyczne

Jednym z częstych problemów jest próba użycia funkcji poza aktywnym kontekstem CATCH. W takim przypadku nie powinno się oczekiwać informacji o dowolnym błędzie, który wystąpił wcześniej w aplikacji. Funkcje ERROR_* są przeznaczone do opisu błędu aktualnie obsługiwanego przez mechanizm TRY...CATCH. Jeżeli zachodzi potrzeba przekazania danych dalej, należy odczytać je w CATCH i dopiero potem wykonać dodatkowe czynności, takie jak zapis do logu lub przekazanie komunikatu.

Drugim problemem jest traktowanie poziomu istotności jako kompletnej diagnozy. Sama liczba nie wskazuje, czy przyczyną było niepoprawne zapytanie, brak obiektu, konflikt danych, ograniczenie uprawnień, przeciążenie zasobu czy chwilowa niedostępność połączenia. W dzienniku powinny znaleźć się co najmniej komunikat, numer, stan, poziom, nazwa procedury oraz numer wiersza. Przydatne bywa także zapisanie czasu, identyfikatora operacji i informacji o komponencie, który wywołał zapytanie.

Problemy pojawiają się również wtedy, gdy komunikat diagnostyczny jest modyfikowany bez zachowania oryginalnych danych. Zbyt ogólny opis, taki jak „operacja nie powiodła się”, utrudnia późniejsze ustalenie źródła awarii. Lepszym rozwiązaniem jest rozdzielenie komunikatu dla użytkownika od szczegółowego wpisu technicznego. Pierwszy może być krótki i zrozumiały, drugi powinien zachować wartości pobrane między innymi przez ERROR_SEVERITY().

W procedurach wielowarstwowych trzeba zwrócić uwagę na ponowne zgłaszanie błędu. Jeżeli wyjątek jest przechwytywany, a następnie przekazywany wyżej, należy zachować jego pierwotny kontekst w sposób zgodny z przyjętym mechanizmem obsługi. W przeciwnym razie w logu może pojawić się poziom odnoszący się do wtórnego błędu, a nie do zdarzenia, które rozpoczęło problem. Ma to znaczenie szczególnie wtedy, gdy jedna procedura wywołuje kolejną i obie posiadają własne bloki TRY...CATCH.

ERROR_SEVERITY() w praktyce kodowania i utrzymania

Najbardziej użyteczny schemat polega na centralnym zbieraniu danych o wyjątkach. W każdym istotnym bloku CATCH można odczytać ERROR_NUMBER(), ERROR_SEVERITY(), ERROR_STATE(), ERROR_PROCEDURE(), ERROR_LINE() i ERROR_MESSAGE(), a następnie przekazać je do wspólnej procedury logującej. Dzięki temu wpisy mają podobną strukturę, łatwiej je przeszukiwać i można tworzyć reguły powiadomień bez analizowania każdego komunikatu ręcznie.

Warto ustalić, które poziomy wymagają natychmiastowej reakcji, a które mogą zostać przeanalizowane zbiorczo. Takie reguły nie powinny opierać się wyłącznie na progu liczbowym. Należy uwzględnić rodzaj operacji, powtarzalność błędu, zakres użytkowników oraz możliwość utraty lub niespójności danych. ERROR_SEVERITY() może być jednym z kryteriów, lecz nie zastępuje testów integralności, monitorowania działania aplikacji ani analizy logów.

Podczas testów warto wywoływać kontrolowane błędy i sprawdzać, czy log zawiera oczekiwane wartości. Należy zweryfikować zachowanie dla błędu składni, naruszenia ograniczenia, braku uprawnienia oraz przerwania transakcji. Dobrze przygotowany test powinien także potwierdzić, że użytkownik otrzymuje bezpieczny komunikat, a szczegóły techniczne nie są przypadkowo ujawniane w interfejsie. Wewnętrzny wpis diagnostyczny może zawierać więcej danych, ale powinien być dostępny wyłącznie dla uprawnionych osób.

ERROR_SEVERITY() może wspierać decyzję o ponowieniu operacji, ale nie powinien samodzielnie uruchamiać automatycznego retry. Ponowienie ma sens tylko wtedy, gdy błąd jest przejściowy, operacja jest idempotentna, a kolejne wykonanie nie spowoduje duplikacji lub częściowego zapisu. W przypadku problemu z logiką zapytania, strukturą danych albo uprawnieniami powtarzanie tej samej czynności zwykle nie rozwiązuje przyczyny i może zwiększyć liczbę wpisów w dzienniku.

ERROR_SEVERITY() i moment zgłoszenia problemu

Do analizy warto przystąpić, gdy błąd powtarza się, przerywa ważną operację, pojawia się po zmianie konfiguracji albo prowadzi do rozbieżności między ekranem aplikacji a zapisanymi danymi. Pomocne jest zachowanie pełnego komunikatu, czasu wystąpienia, nazwy wykonywanej czynności oraz informacji, czy problem wystąpił raz, czy przy każdym podejściu. Jeżeli dostępne są logi, należy zabezpieczyć ich kopię przed zmianami i nie ograniczać opisu do samej wartości ERROR_SEVERITY().

W przypadku problemów z działaniem komputera, aplikacji bazodanowej lub narzędzi używanych do pracy można skorzystać ze wsparcia firmy Warszawskie Pogotowie Komputerowe 24/7. Przed przekazaniem sprzętu lub opisu usterki warto przygotować komunikat błędu, moment jego wystąpienia oraz informację o ostatnich zmianach w systemie. Takie dane ułatwiają oddzielenie problemu sprzętowego od błędu programu, ustawień albo połączenia z bazą danych.

Najważniejsza zasada jest prosta: ERROR_SEVERITY() należy traktować jako element większego obrazu diagnostycznego. Poziom istotności pomaga uporządkować zdarzenia i ustalić priorytety, ale dopiero połączenie go z numerem błędu, komunikatem, miejscem wystąpienia i wpływem na działanie pozwala sformułować wiarygodny wniosek. Takie podejście ułatwia konserwację kodu, poprawia jakość logowania i skraca drogę od pojawienia się wyjątku do znalezienia jego rzeczywistej przyczyny.