你寫的return null正確嗎？

上次一篇「你寫的try…catch真的有必要嗎」引起了很多朋友的討論。本次我在code review又發現了乙個問題，那就是有人有意無意的寫出了return null這樣的**，例如：

public user getuser(guid userid)

這樣的寫法有木有問題？

在我看來沒有充分的理由不應該返回null，因為方法的使用者並不知道在何種條件下會得到null，從而導致臭名昭著的nullreferenceexception異常。

如果由於其他原因導致無法得到乙個user，我們應該丟擲乙個明確的異常供上層服務決定如何處理：

public user getuser(string username, string password)

在我讀過的開源專案中我幾乎沒有見到過return null的寫法。能讓我一時想到的兩個linq方法firstordefault()和lastordefault()，這兩個方法通過命名的方式提醒使用者該方法會返回null。

說到firstordefault()方法讓我想起了很多人容易犯的另乙個錯誤：

public user getuserbyid(guid userid)

在確認資料庫中該userid必須對應乙個user的情況下使用firstordefault()方法，此種場景我會建議你果斷使用single()方法。因為此時使用firstordefault()會隱藏bug。你期望該userid必須得到乙個user，如果single()方法丟擲異常則說明有bug出現，並且讓你在第一時間發現該bug。

f#為了減少null型別的使用引入了option型別，在將option用作函式的返回型別時，如果沒有對未定義的型別做處理，編譯器會報錯。

let invalidint = none
match invalidint with 
| some x -> printfn "the valid value is %a" x
| none -> printfn "the value is none"

如果此處的模式匹配忘記編寫none->分支，編譯器將會報錯，從而提醒你必須處理invalidint值為none時的邏輯。但是在c#中使用null型別，編譯器給予不了我們幫助，所以我們應該避免return null這樣的**，你覺得呢？

剛才搜了一下stackoverflow，發現一篇很有意思的討論 should a retrieval method return 'null' or throw an exception when it can't produce the return value? 我覺得裡面的回答比較準確。

你寫的return null正確嗎？

正確的載入自己寫的dll

讓你寫功能模組你就寫

客戶並非始終正確，你也不是永遠正確的

你寫的return null正確嗎？

正確的載入自己寫的dll

讓你寫功能模組你就寫

客戶並非始終正確，你也不是永遠正確的

相關推薦