2011-04-22 51 views

回答

7

根本不是。

在您的示例中,如果您已經記錄了add需要整數,那麼在該方法開始時約束此約束實際上是很好的做法。

試想一下,你有其他的選擇,以及他們如何壞的是:

  • 不驗證你的論點。這意味着,該方法稍後會失敗,並會出現一個奇怪的回溯,這可能會混淆調用者,並迫使他看看add的執行情況以獲得提示。
  • 很好,並嘗試將輸入轉換爲int - 非常糟糕的主意,用戶會不斷想知道爲什麼add(2.4,3.1)保持返回5
+1

在這樣的情況下,你不喜歡引發異常嗎?我更喜歡只在調試代碼時使用斷言。 – 2011-04-22 12:46:32

+0

它肯定取決於場合(尤其是動態類型語言),但是異常是運行時錯誤,而斷言用於捕獲編程錯誤。如果add的文檔明確聲明它只接受'int',那麼調用者有責任保持這個約束,任何合同違規都是編程錯誤。 – 2011-04-22 12:49:12

+0

(此外,Python中的'assert'引發了'AssertionError' - 所以它實際上是一個合成糖以引發異常)。 – 2011-04-22 12:51:44

2

這沒關係,因爲你可能會-O命令行選項來運行你的應用程序,並會爲您的斷言語句see here

更新不生成代碼:

而且你無論如何都應該處理所有的錯誤。否則,在剝離斷言之後,可能會發生未處理的異常。 (正如McConnell所建議的那樣,請參閱他的引用文章here

+0

這是爲什麼贊成斷言的爭論? – delnan 2011-04-22 12:49:06

+0

我的意思是斷言是好的做法,所以問題是在python腳本中是否存在缺陷。壞的事情是當你的腳本在「釋放」模式下運行時出現斷言異常。但是,python允許你避免這種情況。 – Andrey 2011-04-22 12:55:45

+0

但是,OP的代碼使用斷言進行參數驗證 - 它可能繼續使用錯誤/僞造值,並且如果跳過斷言,則會在稍後崩潰。 – delnan 2011-04-22 12:57:02

0

這不是,但如果你的代碼包含比你的實際代碼更多的assert語句,那麼我會生氣。

0

而不是使用斷言和提出斷言異常...更好地執行適當的檢查使用實例()並引發適當的TypeError。