THROW

THROW zgłasza błąd w T-SQL, przerywając wykonanie bieżącego bloku i przekazując komunikat do wywołującego kodu.

THROW w języku T-SQL

THROW jest instrukcją języka T-SQL używaną w Microsoft SQL Server do zgłaszania błędu albo ponownego przekazania błędu przechwyconego w bloku obsługi wyjątków. Po wykonaniu THROW bieżący przepływ instrukcji zostaje przerwany, a informacja o błędzie może zostać przekazana do kodu wywołującego, procedury nadrzędnej lub aplikacji korzystającej z połączenia z bazą danych. Mechanizm ten stosuje się przede wszystkim w procedurach składowanych, wyzwalaczach i konstrukcji TRY…CATCH.

THROW nie jest poleceniem służącym do logowania ani do naprawiania danych. Jego zadaniem jest jednoznaczne zasygnalizowanie, że wykonanie operacji nie może być kontynuowane zgodnie z założeniami. Dzięki temu aplikacja wywołująca procedurę może otrzymać błąd zamiast wyniku, który wygląda poprawnie, ale został utworzony na podstawie niepełnych lub niespójnych danych.

Składnia zgłaszania własnego błędu

Własny błąd można zgłosić składnią THROW error_number, message, state. Numer błędu musi mieścić się w zakresie od 50000 do 2147483647. Komunikat jest wartością typu nvarchar o maksymalnej długości 2048 znaków, natomiast state jest liczbą od 0 do 255. Parametr state pozwala oznaczyć miejsce lub wariant wystąpienia problemu, ale jego znaczenie nie jest automatycznie definiowane przez SQL Server; interpretację tej wartości ustala autor procedury.

Przykładowo instrukcja THROW 50001, N'Nieprawidłowy identyfikator zamówienia.', 1; może zatrzymać procedurę, gdy przekazany identyfikator nie spełnia warunków walidacji. Po THROW nie powinny znajdować się instrukcje, których wykonanie miałoby być wymagane w normalnym przebiegu tej samej gałęzi, ponieważ zgłoszenie błędu kończy bieżący przepływ. W praktyce przed instrukcją THROW należy stosować średnik kończący poprzednią instrukcję, ponieważ parser T-SQL wymaga odpowiedniego zakończenia poprzedzającego polecenia.

THROW razem z TRY…CATCH i transakcją

Najczęstszy wzorzec użycia polega na umieszczeniu operacji w bloku TRY i obsłudze błędu w bloku CATCH. W bloku CATCH bez parametrów można użyć samego THROW, aby ponownie zgłosić aktualnie obsługiwany błąd. Takie ponowne zgłoszenie zachowuje informacje o błędzie, między innymi jego numer, komunikat, stan oraz dane dotyczące miejsca wystąpienia. Jest to istotne, gdy niższa warstwa nie może samodzielnie rozstrzygnąć, jak należy zareagować.

Przy operacjach obejmujących kilka zmian danych THROW powinien być analizowany razem z transakcją. Samo zgłoszenie błędu nie oznacza automatycznie, że każda wcześniejsza zmiana została cofnięta. Procedura może sprawdzić stan transakcji za pomocą XACT_STATE(), a następnie wycofać transakcję, jeśli pozostaje ona aktywna i możliwa do zatwierdzenia lub cofnięcia. W przypadku włączenia SET XACT_ABORT ON błędy zgłaszane przez THROW powodują automatyczne zakończenie i wycofanie bieżącej transakcji. Dlatego ustawienie XACT_ABORT, zakres transakcji i miejsce wykonania THROW muszą być projektowane jako jeden przepływ.

Różnice między THROW a RAISERROR

THROW i RAISERROR służą do przekazywania błędów, ale nie są identycznymi mechanizmami. THROW został wprowadzony w SQL Server 2012 i zapewnia prosty sposób ponownego zgłaszania błędu z bloku CATCH. Przy samodzielnym zgłaszaniu błędu przez THROW używany jest poziom ważności 16, dlatego nie przekazuje się go jako osobnego parametru. Instrukcja THROW nie obsługuje również bezpośrednio argumentów formatowania w taki sposób jak RAISERROR.

Jeżeli komunikat musi zawierać wartości dynamiczne, można wcześniej przygotować jego treść, na przykład za pomocą FORMATMESSAGE, a następnie przekazać gotowy tekst do THROW. Nie należy zastępować numeru błędu dowolną wartością tylko po to, aby uzyskać określony opis w aplikacji. Numer, komunikat i state powinny wspólnie wskazywać rzeczywisty rodzaj oraz miejsce problemu. Podczas diagnostyki błędów w aplikacji korzystającej z Microsoft SQL Server sprawdza się więc definicję procedury, warunki wejściowe, obsługę TRY…CATCH, stan transakcji i sposób interpretowania błędów przez kod wywołujący.