TEST

2010年6月17日 星期四

ASSERT的使用時機

ASSERT全大寫表示它是全域的。它是一種假設,當假設不成立時,程式就得全部中止。且只作用在Debug時,為的就是讓你在Debug時可以更快地寫程式、找出錯誤。Release時會不會假設就不成立了?有可能,但通常寫程式Debug時就會出現ASSERT出錯的情況,在此時就會快速的發現錯誤,如果Relese版本才出錯,就是考慮的不夠嚴謹,有些ASSERT沒有設定,或是某種情況Relese版才出現。此時更需要Unit Test配合。

寫程式需不需要到處都先假設?

被呼叫端的函式比如fun(obj * o);就必須成立一假設ASSERT(NULL!=o);
為何不return error code或throw exception,要考慮的是上層有沒有檢查就呼叫。通常是會檢查的,就沒有返回錯誤碼或丟例外的必要,但並不能保證。

如果上層要檢查那上上層要不要檢查?在每一層都必須檢查是無謂的。

通常一個軟體設計會分成三個模組,也就是所謂的MVC,是指模組而言。在程式邏輯可分成Controller、UI、Library三層,是有點類似的。Controller呼叫UI和Library,而UI傳送使用者event給Controller。在大型的軟體,可能Controller上還會有一個總體的Controller,Library可能還會呼叫別的Library。
實際的程式可能是C1->C2->L1->L2->L3,UI可能由C1整合(C1<->UI),

設有一程式輸入名子就可以知道工作時數來取得Payment(薪水、股票)
UI(input)<->C1->C2->
fun1(string name)->fun2(int work_time)->fun3(Payment * pay);

fun1就必須有ASSERT(!name.IsEmpty());
fun2就必須有ASSERT(work_time>0);
fun3就必須有ASSERT(NULL!=pay);

在此情況*下L1,L2,L3都必須ASSERT,而C1或C2就必須檢查避免傳遞無效名子。Controller會去使用UI跟Library,被呼叫端UI跟Library就必須要假設是被正常使用。

但Controller不能有ASSERT,因為它不能有任何的假設情況,必須把會發生的都考慮進去,遇到不正常的時候就阻擋。而被呼叫端都必須要確認情況是成立的才能繼續執行。煩惱就交給上層,下層就只要假設就好了。

C++ 編程規範70提到error有三種:

  • Precondition(前條件)
  • Postcondition(後條件)
  • Invariant(不變性)

書中講得很清楚,在此不重述。只有不變性比較抽象,不變性就是滿足一個有效狀態(valid states)物件的條件。比如說一個有帳號、密碼的物件,帳號和密碼必須是成對且正確對應的,其中一個有錯就是error、無效狀態。這很明顯不該使用ASSERT來保證*。

書中說到Postcondition也可用ASSERT來確認:

"假設你呼叫某個API函式,其文件說它總是返回正值,但你懷疑該函式有臭蟲,那麼你可以在呼叫該函式後使用assert驗證其結果。"

這我認為是多餘的,不是很建議。當此API函式出錯有兩種解法:

  • API可以修改:修改API錯誤,但不管Debug還是Release時還是要再確認。
  • API不可修改:此時也不能用ASSERT中止,且Release版本也不希望出現這個錯誤,當然是由上層想辦法檢查繞過來解決。

不管Debug還是Release時,你還是得再一次確認結果是你所預期的,此時可搭配Unit Test來確認。要不然就是上層自行檢查來避開,沒有必要用ASSERT。Postcondition真的有需要ASSERT時,我覺得只有在驗算的時候,比如設計類似Excel的軟體,寫了兩個演算法來計算同樣的數學式,一個是用來驗算,而且只有Debug版本會算兩次比較慢,不相等的話就一定是其中一個有錯。

總結ASSERT的使用時機:

  • Precondition
  • 當你寫的程式是被使用的UI或Library,請多多利用ASSERT來防範吧。

*這只是假命題,fun1也可以接受空名子再處理,fun2可以用unsign int限制,fun3也可以傳reference防null物件,所以實際上用到ASSERT的情況不多。
*不要用ASSERT報告執行期錯誤[C++ 編程規範68]。