Лучшие практики для API хранимых процедур?

Question

Мы добавляем в наш продукт некоторые хранимые процедуры, которые могут вызываться сторонними клиентами. Существуют ли передовые практики для проверки параметров, возвращаемых значений, RAISERROR и т. Д.?

Сторонние клиенты не будут иметь прямого доступа к таблицам, только к определенным sprocs. Таблица, затронутая sprocs, хорошо ограничена, но мы хотим быть максимально удобными для пользователя, чтобы предоставлять подробную информацию об ошибках, когда sprocs вызывается неправильно.

Answer 1

• Использовать блоки TRY / CATCH
• Бросать значимые сообщения (я использую префикс, такой как "INFO:", чтобы отличить мои ошибки от ошибок базы данных)

Пример:

SET NOCOUNT, XACT_ABORT ON
...
BEGIN TRY
    IF @parameter1 IS NULL
        RAISERROR ('INFO: "parameter1" should not be blank', 16, 1)

    IF @parameter2 < 0
        RAISERROR ('INFO: "parameter2" must be greate then zero', 16, 1)

    ...

END TRY
BEGIN CATCH
    DECLARE @MyError nvarchar(2048)
    SELECT @MyError = ERROR_MESSAGE() -- + other stuff, like stored proc name perhaps
    RAISERROR (@MyError, 16, 1)
    ...
END CATCH

Answer 2

Нетрудно предоставить информационные сообщения об ошибках, понятные человеку. Просто RAISERROR с описательным текстом. Немного сложнее поднять локализованные тексты, что предполагает правильное использование sp_addmessage и семейства. Реальная трудная проблема - это ошибка, на которую может реагировать программа. Это означает правильно документированные коды ошибок ( и серьезность и состояние) и строгую дисциплину кода при использовании их в вашем API.

И не забывайте правильное вложение транзакций. В моем блоге есть пример того, как правильно обрабатывать транзакции в сочетании с исключениями T-SQL: Обработка исключений и вложенные транзакции .

К сожалению, современное состояние всего стека клиент / T-SQL в отношении исключений имеет некоторые проблемы. Наиболее примечательным является то, что если вы перехватываете исключение T-SQL, вы не можете перебросить его, поэтому ваш клиент не может ожидать типичных чисел системных ошибок. См. SQL Server: Возврат исключения с исходным номером исключения . Это оставляет вам мало средств для передачи правильной информации об ошибках, кроме использования ваших собственных номеров ошибок в диапазоне более 50000, что очень громоздко, так как увеличивается число «преобразованных» кодов ошибок, и использование строки сообщения об ошибке в качестве информации об исключении .