從函數(shù)返回?cái)?shù)據(jù)時(shí)的最佳實(shí)踐是什么。返回Null還是空對象更好？又為什么一個(gè)要比另一個(gè)做呢？考慮一下：public UserEntity GetUserById(Guid userId){ //Imagine some code here to access database..... //Check if data was returned and return a null if none found if (!DataExists) return null; //Should I be doing this here instead? //return new UserEntity(); else return existingUserEntity;}讓我們假裝將有此計(jì)劃，將有與該GUID數(shù)據(jù)庫中沒有用戶信息的有效案例。我可以想象在這種情況下拋出異常是不合適的？另外，我的印象是異常處理會(huì)損害性能。
3 回答
烙印99
TA貢獻(xiàn)1829條經(jīng)驗(yàn) 獲得超13個(gè)贊
返回null通常是最好的主意，如果你打算表示沒有數(shù)據(jù)可用。
一個(gè)空的對象意味著數(shù)據(jù)已經(jīng)返回，而返回null清楚地表明，什么也沒有返回。
此外，如果您嘗試訪問對象中的成員，則返回null會(huì)導(dǎo)致null異常，這對于突出顯示錯(cuò)誤代碼很有用-嘗試不訪問任何成員都是沒有意義的。訪問空對象的成員不會(huì)失敗，這意味著錯(cuò)誤可能會(huì)被發(fā)現(xiàn)。
料青山看我應(yīng)如是
TA貢獻(xiàn)1772條經(jīng)驗(yàn) 獲得超8個(gè)贊
這取決于哪種情況最適合您的情況。
是否有意義返回空值，例如：“沒有這樣的用戶存在”？
還是創(chuàng)建默認(rèn)用戶有意義？這是很有道理的，當(dāng)你可以安全地假設(shè)，如果用戶不存在，調(diào)用代碼打算為一個(gè)，當(dāng)他們要求它存在。
或者是否有意義拋出一個(gè)異常（一拉“FileNotFound”）如果調(diào)用代碼是要求苛刻的用戶使用無效的ID？
但是，從關(guān)注點(diǎn)/ SRP的角度來看，前兩個(gè)更正確。從技術(shù)上講，第一個(gè)是最正確的（但僅憑一根頭發(fā)）-GetUserById僅應(yīng)負(fù)責(zé)一件事-獲取用戶。通過返回其他內(nèi)容來處理自己的“用戶不存在”的情況可能違反了SRP。分開檢查- bool DoesUserExist(id)如果您確實(shí)選擇引發(fā)異常，則比較合適。
基于下面的大量評論：如果這是API級設(shè)計(jì)問題，則此方法可能類似于“ OpenFile”或“ ReadEntireFile”。我們正在從某個(gè)存儲(chǔ)庫“打開”用戶，并從結(jié)果數(shù)據(jù)中添加對象。在這種情況下，例外可能是適當(dāng)?shù)?。可能不是，但可能是?/p>
所有方法都是可以接受的-這取決于API /應(yīng)用程序的較大上下文。
繁華開滿天機(jī)
TA貢獻(xiàn)1816條經(jīng)驗(yàn) 獲得超4個(gè)贊
如果特定合同違約，則應(yīng)該（僅）引發(fā)異常。
在您的特定示例中，基于已知ID詢問UserEntity，這取決于事實(shí)（如果缺少（刪除）用戶）是預(yù)期情況。如果是這樣，則返回，null但是如果不是預(yù)期的情況，則拋出異常。
請注意，如果調(diào)用該函數(shù)，UserEntity GetUserByName(string name)則可能不會(huì)拋出該異常，但返回null。在這兩種情況下，返回一個(gè)空的UserEntity都是無濟(jì)于事的。
對于字符串，數(shù)組和集合，情況通常是不同的。我記得一些準(zhǔn)則形式的MS，方法應(yīng)將其接受null為“空”列表，但返回零長度而不是的集合null。字符串也一樣。請注意，您可以聲明空數(shù)組：int[] arr = new int[0];
- 3 回答
- 0 關(guān)注
- 994 瀏覽
添加回答
舉報(bào)
0/150
提交
取消