Đây là một phần của mẫu thủ tục được lưu trữ mà tôi sử dụng:
/* CREATE PROCEDURE... */
DECLARE
@ErrorMessage varchar(2000)
,@ErrorSeverity tinyint
,@ErrorState tinyint
/* Additional code */
BEGIN TRY
/* Your code here */
END TRY
BEGIN CATCH
SET @ErrorMessage = ERROR_MESSAGE()
SET @ErrorSeverity = ERROR_SEVERITY()
SET @ErrorState = ERROR_STATE()
RAISERROR(@ErrorMessage, @ErrorSeverity, @ErrorState)
BREAK
END CATCH
/* Further cleanup code */
Các khối Try / Catch có thể phức tạp nhưng triệt để hơn nhiều so với lỗi @@. Quan trọng hơn, bạn có thể sử dụng các hàm error_xxx () khác nhau bên trong chúng. Ở đây, tôi lưu trữ thông báo lỗi thích hợp trong biến @ErrorMessage, cùng với đủ dữ liệu khác để phát hiện lại lỗi. Từ đây, bất kỳ tùy chọn nào đều có sẵn; bạn có thể đặt @ErrorMessage thành một biến đầu ra, kiểm tra và xử lý các lỗi cụ thể hoặc xây dựng các thông báo lỗi của riêng bạn (hoặc điều chỉnh các thông báo lỗi hiện có để rõ ràng hơn - bạn có thể khó chịu khi biết tần suất bạn muốn làm điều đó). Các tùy chọn khác sẽ trình bày các món đồ nhỏ.
Một số điều cần lưu ý:trong một số trường hợp, SQL sẽ ném hai thông báo lỗi trở lại ... và error_message() sẽ chỉ bắt cái cuối cùng, thường có nội dung như "cố gắng tạo đối tượng không thành công", với lỗi thực sự được đưa ra trong thông báo lỗi đầu tiên. Đây là nơi tạo ra thông báo lỗi của riêng bạn.
