將我引發的錯誤與其他 SQL Server 錯誤區分開來
在我的儲存過程中，當業務規則被破壞時，我會引發一個錯誤，該錯誤會冒泡到 C# 客戶端應用程序並顯示給使用者。例如
RAISERROR('Hey, you cannot do that because blah blah blah', 16, 1);我想將我引發的錯誤與其他 SQL Server 錯誤區分開來，因為我只想顯示我的錯誤。
我認為這些是向客戶端應用程序發送消息的唯一方法，這是要顯示的使用者消息：嚴重級別、狀態、返回程式碼。但我認為我應該離開嚴重級別。
- 如何告訴我的客戶端應用程序？
- 我應該使用什麼尚未使用的程式碼或號碼？
- 或者有沒有我沒有考慮過的另一種方式？
或者我應該這樣做：
THROW 50000, 'Hey, you cannot do that!', 1;編輯（2022 年 4 月 13 日） 我問 Erland Sommarskog，他的回答幫助我意識到，如果你使用這個
RAISERROR('Hey, you cannot do that because blah blah blah', 16, 1);…然後客戶端應用程序將始終獲得 50000 作為錯誤號。使用 RAISERROR，您可以使用參數化消息。您只需要注意 RAISERROR 不會退出批處理。所以，對我來說，RAISERROR 贏了。
THROW無論如何，您都應該使用，因為Microsoft 的文件有些不推薦RAISERROR使用*：*RAISERROR 語句不支持 SET XACT_ABORT。新應用程序應使用 THROW 而不是 RAISERROR。
根據上的文件
THROW，該error_number參數必須是大於或等於 50000 且小於或等於 2147483647 的數字。（前 49,999 個錯誤程式碼已為本地 SQL Server 生成的錯誤保留。）如果您在客戶端應用程序中使用 C#，那麼當您的應用程式碼從 SQL Server 接收到異常時，該異常對象將被強制轉換為一個
SQLException對象。（System.Data.SqlException對象，如果您仍在使用舊的程序集引用。）這將公開您拋出的自定義異常的所有屬性，特別是該Number屬性將包含您的自定義錯誤程式碼。就個人而言，我喜歡為我在 SQL Server 實例中使用的每個使用者定義的錯誤程式碼保留一個列舉集合。
如果您確實選擇繼續使用
RAISERROR，您還可以考慮創建和使用您自己的使用者定義的錯誤消息，sp_addmessage以將實際消息重構為 SQL Server 中的自定義錯誤程式碼，以便您每次都可以引用相同的對象你拋出同樣的異常。（雖然我個人以前從未使用過此功能。）但我個人建議堅持使用THROW.