T-SQL - вернуть пользовательское сообщение об ошибке и завершить запрос

У меня есть длинная хранимая процедура, в которой я хотел бы сделать что-то вроде следующего:

IF @SubPageDirectory IS NULL
BEGIN
    RAISERROR('@SubPageDirectory cannot be NULL', 10, 1)
    EXIT STORED PROCEDURE
END

В основном я хочу проверить, является ли моя переменная NULL, и, если это так, вернуть сообщение об ошибке моему веб-приложению .NET и прекратить выполнение запроса на этом этапе. Как я могу этого добиться?


tsql sql-server-2005 asp.net-3.5 raiserror
person Curt    schedule 15.07.2010    source источник

Ответы (1)


arrow_upward

arrow_downward

person    schedule
comment
@DaveShaw: нет, он продолжает выполнение - person gbn; 15.07.2010
comment
RETURN, кажется, возвращается без каких-либо ошибок, например, он не показывает пользователю ошибки, он просто будет продолжаться. RAISERROR сам по себе продолжает чтение хранимой процедуры, поскольку затем вызывает другую ошибку. - person Curt; 15.07.2010
comment
+1, однако, я бы сделал это RETURN n, где n - целое число. Я делаю предупреждающие сообщения об отрицательных возвращаемых значениях (недопустимый ввод данных пользователем и т. Д.), А положительные возвращаемые значения - фатальные ошибки (ошибка вставки и т. Д.). Вызывающее приложение может определить, как обрабатывать сообщение (жесткая остановка и / или просто отображение сообщения) на основе положительного / отрицательного возвращаемого значения. - person KM.; 15.07.2010
comment
Я увеличил уровень серьезности до 16, и теперь мое веб-приложение asp.net показывает страницу с ошибкой сервера, на что я и надеялся. Возврат также предотвратил продолжение запроса. Раньше я упускал из виду комментарий о повышении уровня серьезности. - person Curt; 15.07.2010
comment
К сожалению, уровень серьезности 16 означает, что он определен пользователем. 10 - это предупреждение, которое обычно игнорируется - person gbn; 15.07.2010
comment
Спасибо @gbn, очень признателен! - person Curt; 15.07.2010
comment
@gbn и @KM: Кажется, я не могу найти документы, которые разъясняют это, но из моего тестирования кажется, что если raiseerror вызывается в SProc, то при вызове из: 1.1. Приложение .NET создаст исключение .NET и, следовательно, не сможет проверить код возврата 1.2. Окно запроса SSMS или другой SProc или функция будут иметь свои значения Param, отображаемые на вкладке сообщений (если из SSMS), и не будут иметь программного способа T-SQL для получения значений параметров raiseerror, но код возврата можно проверить программно. Правильный? - person Tom; 06.10.2017
comment
@Том. Если честно, я бы не стал полагаться на коды возврата. И я ими вообще не пользуюсь. При необходимости используйте состояние (последний параметр RAISERROR) или добавьте код в строку. Оба могут быть проанализированы в обработчике исключений -net. - person gbn; 06.10.2017
comment
@gbn: AFAIK, у вас нет возможности проверить код возврата в .NET, если был вызван raiseerror. Я думаю, что коды возврата полезны тем, что они допускают определенную логику, не полагаясь / не ограничивая сообщения об ошибках, которые / остаются в определенном формате. А как насчет того, когда Sprocs с raiseerror вызовами вызываются из T-SQL. Знаете ли вы, как через T-SQL запросить значения параметров вызова raiseerror из T-SQL? - person Tom; 06.10.2017
comment
@Tom DECLARE @rtn int; EXEC @rtn = MyStoredProc @p1.. Кроме того, 1 в RAISERROR - это состояние, которое может передавать информацию. См. Также sommarskog.se/error-handling-I.html#returnvalue - person gbn; 09.10.2017
comment
@gbn: 1. Спасибо за ссылку! Однако я чувствую, что Матрица мне открылась. ;) Я знал, что обработка ошибок SS странная, но не настолько!?! Невежество - это блаженство. 2. Это все еще не дает ответа на мой вопрос о том, как через T-SQL запросить значения параметров вызова raiseerror из T-SQL. 3. Понятно (поскольку последнее обновление было обновлено 29.11.09), в нем говорится: «К сожалению, вы не можете повторно вызвать точное сообщение об ошибке, поскольку RAISERROR не позволяет вам использовать номера ошибок менее 50000. С SS 2012 вы можете позвонить в Thow. (без параметров), чтобы повторно выдать точное сообщение об ошибке. - person Tom; 09.10.2017
comment
@Tom: Я использую THROW почти исключительно - person gbn; 10.10.2017
comment
@gbn: Я бы тоже, но я не писал raiseerror Calls, а они на SS ‹2012. - person Tom; 11.10.2017