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