將Trace.Assert
和Debug.Assert
語句保留在「穩定」且已移入測試和生產環境的代碼中是否明智?.NET生產代碼中的'斷言'語句
如果是這樣,這些斷言聲明如何提供幫助? Guard類是否足以檢查異常情況並根據情況提出異常情況?
將Trace.Assert
和Debug.Assert
語句保留在「穩定」且已移入測試和生產環境的代碼中是否明智?.NET生產代碼中的'斷言'語句
如果是這樣,這些斷言聲明如何提供幫助? Guard類是否足以檢查異常情況並根據情況提出異常情況?
Debug.Assert語句將被忽略,除非您定義了DEBUG編譯常量,默認情況下,當您在「debug」配置中進行編譯而不是在「release」配置中進行編譯時。事實上,Debug類只能用在測試環境中,在那裏你應該捕獲所有(或者至少大部分)會導致Debug.Assert失敗的bug。
Trace.Assert以同樣的方式工作,只是必須存在的編譯常量是TRACE,默認情況下它存在於「debug」和「release」配置中。在釋放代碼中使用跟蹤斷言可能是有意義的,但通常最好讓它們做的不是方法的默認行爲(它只是顯示帶有堆棧跟蹤的消息框)。您可以通過爲Trace類配置自定義跟蹤偵聽器來實現此目的;請參閱方法文檔瞭解更多詳細信息。
斷開異常的好處之一是你可能不會在發生問題的地方捕捉異常。但斷言總是發生在正確的地方。
Assert我能想到的另一個好處是它可以幫助您在生產環境中進行調試。在發佈代碼中仍然有效的斷言可以在運行時通過適當的工具動態捕獲,例如DbgView。在您的產品發佈後,這對於調試非常方便。
http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx
移動至正式發佈環境是一個開始,而不是程序的生命的結束。 一旦它符合真實的用戶和現實世界,您將開始獲得大量有關 問題和需求的反饋,但您並未預料到。 這意味着,開發纔剛剛開始。 你需要你的斷言來幫助你儘早地發現錯誤的假設(在 之前他們犯了很多問題),並幫助你擴展和改變你的程序。
+1維護思維... – 2009-11-30 11:21:28