在comp.lang.c ++。moderated上有一個討論，討論是否應(yīng)將斷言（應(yīng)在C ++中默認情況下僅存在于調(diào)試版本中）保留在生產(chǎn)代碼中。顯然，每個項目都是獨特的，所以在這里我的問題是沒有這么多是否斷言應(yīng)該保持，但在這情況下，這是值得推薦的/不是一個好主意。斷言是指：一種運行時檢查，用于測試條件，如果條件為false，則表明該軟件存在錯誤。暫停程序的一種機制（可能是在清理工作最少之后）。我不一定要談?wù)揅或C ++。我個人的意見是，如果您是程序員，但不擁有數(shù)據(jù)（大多數(shù)商業(yè)桌面應(yīng)用程序就是這種情況），則應(yīng)保留它們，因為斷言失敗會顯示錯誤，并且您不應(yīng)該去帶有錯誤，可能會損壞用戶的數(shù)據(jù)。這迫使您在發(fā)貨之前進行嚴格的測試，并使錯誤更明顯，從而更容易發(fā)現(xiàn)和修復(fù)。您的看法/經(jīng)驗是什么？干杯，卡爾在這里查看相關(guān)問題回應(yīng)和更新嘿，格雷厄姆，斷言是錯誤，純凈而簡單的斷言，因此應(yīng)像對待一個斷言一樣處理。由于應(yīng)該在發(fā)布模式下處理錯誤，因此您實際上不需要斷言。這就是為什么我在談?wù)摂嘌詴r更喜歡“ bug”一詞的原因。它使事情變得更加清晰。對我來說，“錯誤”一詞太含糊。丟失的文件是錯誤，而不是錯誤，程序應(yīng)處理該文件。嘗試取消引用空指針是一個錯誤，程序應(yīng)該承認有些東西聞起來像不好的奶酪。因此，您應(yīng)該使用斷言測試指針，但是使用正常的錯誤處理代碼來測試文件的存在。話題不大，但在討論中很重要。請注意，如果斷言失敗時您的斷言進入調(diào)試器，為什么不這樣做。但是有很多原因?qū)е挛募淮嬖?，這完全超出了代碼的控制范圍：讀/寫權(quán)限，磁盤已滿，USB設(shè)備拔出等。由于您無法控制它，因此我認為是斷言不是正確的處理方式?？柾旭R斯是的，我有完整的代碼，必須說我完全不同意該建議。假設(shè)您的自定義內(nèi)存分配器已擰緊，并將零塊仍由其他對象使用的內(nèi)存清零。我碰巧將一個該對象定期取消引用的指針歸零，其中一個不變因素是該指針永遠不會為null，并且您有幾個斷言來確保它保持這種狀態(tài)。如果指針突然為空，該怎么辦。您只是圍繞它if（），希望它能正常工作？記住，我們在這里談?wù)摦a(chǎn)品代碼，因此不會破壞調(diào)試器并檢查本地狀態(tài)。這是用戶計算機上的實際錯誤?？?