Разумно ли использовать «состояние», чтобы указать клиенту номер ошибки?

Question

Я пишу хранимую процедуру Transact- SQL и хочу иметь возможность сообщать об ошибке клиенту приятным заданным способом c, без необходимости прибегать к сопоставлению строки.

Я знаю, что можно использовать значение RETURN, но я сообщаю об ошибках с RAISERROR (это также относится к новому ключевому слову THROW). Одним из способов является использование идентификатора сообщения об ошибке вместо строки, но для этого необходимо, чтобы идентификатор был больше 50000, зарегистрирован в каталоге sys.messages и не позволяло хранимой процедуре возвращать как строку сообщения об ошибке, так и идентификатор.

Одна вещь, которая привлекла мое внимание, была "состояние". Якобы это для определения того, где в SP произошла конкретная ошибка c, если одна и та же ошибка возникла более чем в одном месте, но я не вижу причин, почему ее не следует просто использовать для идентификатора сообщения об ошибке. Должно ли это работать нормально, или есть причина, по которой я не должен использовать его таким образом?

Answer 1

Обратите внимание, что вы не должны использовать RaiseError в своей хранимой процедуре.
Страница документации RaiseError начинается с этого оператора:

Примечание: Оператор RAISERROR не поддерживает SET XACT_ABORT. Новые приложения должны использовать THROW вместо RAISERROR.

При этом краткий ответ на ваш вопрос таков: если у вас меньше 257 ошибок, вы можете использовать state свойство различать guish между ними, даже если это не лучший способ действий.

Более длинный ответ требует некоторого фона:

Мы начнем с рассмотрения Throw список аргументов:

номер_ошибки
Константа или переменная, представляющая исключение. error_number равен int и должен быть больше или равен 50000 и меньше или равен 2147483647.

message
Строка или переменная, описывающая исключение. сообщение: nvarchar(2048).

состояние Это константа или переменная в диапазоне от 0 до 255, которая указывает состояние, связанное с сообщением. состояние tinyint.

Обратите внимание, что далее внизу страницы есть короткая таблица, указывающая разницу между RaiseError и Throw - которая утверждает, что при использовании throw, Параметр error_number необязательно определять в sys.messages (в отличие от аргумента msg_id RaiseError).

По общему признанию, эта страница документации мало что говорит о параметре State, поэтому давайте посмотрим на страницу документации функции ERROR_STATE().
Раздел примечаний начинается со следующего утверждения:

Некоторые сообщения об ошибках могут появляться в нескольких точках в коде для Microsoft SQL Server Database Engine. Например, ошибка «1105» может возникать для нескольких различных условий. Каждое указанное c условие, которое вызывает ошибку, присваивает уникальный код состояния.

Это в основном означает, что параметр State на самом деле является идентификатором, предназначенным для различения guish между аналогичными ошибками это вызвано различными условиями.

Итак, в заключение - я бы, вероятно, посоветовал не использовать state в качестве идентификатора ошибки, а просто использовать для этого error_number, оставляя возможность использовать state в качестве он был разработан для использования.