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