try/catch塊VS SQL檢查

不久，我想知道以下哪些是更好的做法：try/catch塊VS SQL檢查

封裝我的代碼在TRY/CATCH塊，並顯示錯誤消息
寫自己的檢查和顯示自定義錯誤信息

因爲我已經閱讀了TRY/CATCH塊沒有處理所有類型的錯誤。在我的情況下，這不是一個問題。

我正在構建執行特定存儲過程的動態SQL。我可以做我自己的檢查，如：

是將要執行存在
供應
可以將所有值的所有參數正確地轉換

，或者只是封裝過程這樣的說法：

BEGIN TRY   
    EXEC sp_executesql @DynamicSQLStatement 
    SET @Status = 'OK' 
END TRY 
BEGIN CATCH 
    SET @Status = ERROR_MESSAGE() 
END CATCH

如果我自己做檢查有沒有什麼區別（f或示例性能差異）或我應該離開這項工作到服務器？

我問的原因是因爲在某些語言（如JavaScript）中使用try/catch塊被稱爲不好的做法。

來源

2013-11-21 gotqn

通常情況下最好自己檢查這些東西，而不是讓SQL Server捕獲異常。異常處理是不便宜，因爲我證明這些帖子：

Checking for potential constraint violations before entering SQL Server TRY and CATCH logic

Performance impact of different error handling techniques

根據不同的模式，音量，併發性，期待與您失敗的頻率，你的引爆點可能會有所不同，所以在很高的範圍內，這可能並不總是最有效的方式。但除了事實上，在大多數情況下，您的狀況會更好，編寫自己的錯誤處理和預防 - 儘管需要時間 - 可讓您充分了解所有錯誤情況。

也就是說，你仍然應該有TRY/CATCH作爲故障安全，因爲總會有一些你沒有預料到的例外，優雅地吹起來比扔碎片要好得多。

來源

2013-11-21 17:13:32

非常感謝，對您的文章的引用正是我所期待的。 – gotqn

try/catch應該只用於嚴重錯誤。如果有可能的錯誤，你可以通過做一個簡單的if語句來阻止，你應該這樣做。例如，不要依賴try/catch來確保用戶以正確的格式輸入日期。檢查一下你自己。個人而言，如果我得到這樣的關鍵異常，我更願意看到調用堆棧以及它發生的位置。所以，我只在我的項目的最頂層做一個try/catch。

來源

2013-11-21 16:56:31 Scottie

使用Try Catch Block，您仍然可以引發自定義錯誤消息，實際上，如果您有自定義錯誤消息，則只能顯示自定義錯誤消息，您不能使用sql server默認錯誤消息。您還可以使用許多其他錯誤功能，以及讓你的錯誤更多的信息，像

ERROR_LINE() 
ERROR_MESSAGE() 
ERROR_STATE() 
ERROR_NUMBER() 
ERROR_STATE(),

只能在try/catch塊的catch塊中這些功能，使我們的靜物一個很容易作爲開發人員:)

來源

2013-11-21 16:59:32

try/catch塊VS SQL檢查

回答

相關問題