Haruskah fungsi mengembalikan null atau objek kosong?

Apa praktik terbaik saat mengembalikan data dari fungsi. Apakah lebih baik mengembalikan Null atau objek kosong? Dan mengapa seseorang harus melakukan satu dari yang lain?

Pertimbangkan ini:

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;
}

Mari kita berpura-pura bahwa akan ada kasus yang valid dalam program ini bahwa tidak akan ada informasi pengguna dalam database dengan GUID itu. Saya akan membayangkan bahwa tidak pantas untuk melemparkan pengecualian dalam kasus ini ?? Saya juga mendapat kesan bahwa penanganan pengecualian dapat merusak kinerja.

Mengembalikan nol biasanya merupakan ide terbaik jika Anda bermaksud menunjukkan bahwa tidak ada data yang tersedia.

Objek kosong menyiratkan data telah dikembalikan, sedangkan pengembalian nol dengan jelas menunjukkan bahwa tidak ada yang dikembalikan.

Selain itu, mengembalikan nol akan menghasilkan pengecualian nol jika Anda mencoba mengakses anggota di objek, yang dapat berguna untuk menyoroti kode buggy - mencoba mengakses anggota yang tidak ada artinya tidak masuk akal. Mengakses anggota objek kosong tidak akan gagal berarti bug tidak dapat ditemukan.

Tergantung pada apa yang paling masuk akal untuk kasus Anda.

Apakah masuk akal untuk mengembalikan nol, misalnya "tidak ada pengguna seperti itu"?

Atau masuk akal untuk membuat pengguna default? Ini masuk akal ketika Anda dapat dengan aman berasumsi bahwa jika pengguna TIDAK ADA, kode panggilan berniat untuk ada ketika mereka memintanya.

Atau apakah masuk akal untuk melemparkan pengecualian (ala "FileNotFound") jika kode panggilan menuntut pengguna dengan ID yang tidak valid?

Namun - dari pemisahan keprihatinan / sudut pandang SRP, dua yang pertama lebih benar. Dan secara teknis yang pertama adalah yang paling benar (tetapi hanya dengan rambut) - GetUserById hanya bertanggung jawab untuk satu hal - mendapatkan pengguna. Menangani kasus "pengguna tidak ada" sendiri dengan mengembalikan sesuatu yang lain bisa menjadi pelanggaran SRP. Memisahkan menjadi cek yang berbeda - bool DoesUserExist(id)akan sesuai jika Anda memilih untuk melemparkan pengecualian.

Berdasarkan komentar ekstensif di bawah ini : jika ini adalah pertanyaan desain tingkat API, metode ini dapat dianalogikan dengan "OpenFile" atau "ReadEntireFile". Kami "membuka" pengguna dari beberapa repositori dan menghidrasi objek dari data yang dihasilkan. Pengecualian bisa sesuai dalam kasus ini. Mungkin tidak, tetapi bisa juga.

Semua pendekatan dapat diterima - itu hanya tergantung, berdasarkan konteks API / aplikasi yang lebih besar.

Secara pribadi, saya menggunakan NULL. Itu membuat jelas bahwa tidak ada data untuk kembali. Tetapi ada beberapa kasus ketika Obyek Null mungkin berguna.

Jika jenis pengembalian Anda adalah sebuah array maka kembalikan array kosong jika tidak mengembalikan null.

Anda harus melempar pengecualian (hanya) jika kontrak tertentu rusak.
Dalam contoh spesifik Anda, meminta UserEntity berdasarkan ID yang dikenal, itu akan tergantung pada kenyataan jika pengguna yang hilang (dihapus) adalah kasus yang diharapkan. Jika demikian, kembalilah nulltetapi jika itu bukan kasus yang diharapkan, maka lontarkan pengecualian.
Perhatikan bahwa jika fungsi dipanggil UserEntity GetUserByName(string name)mungkin tidak akan melempar tetapi mengembalikan null. Dalam kedua kasus mengembalikan UserEntity kosong akan tidak membantu.

Untuk string, array dan koleksi situasinya biasanya berbeda. Saya ingat beberapa bentuk pedoman MS bahwa metode harus menerima nullsebagai daftar 'kosong' tetapi mengembalikan koleksi panjang nol daripada null. Hal yang sama untuk string. Perhatikan bahwa Anda dapat mendeklarasikan array kosong:int[] arr = new int[0];

Ini adalah pertanyaan bisnis, tergantung pada apakah keberadaan pengguna dengan ID Panduan spesifik merupakan kasus penggunaan normal yang diharapkan untuk fungsi ini, atau apakah ini merupakan anomali yang akan mencegah aplikasi untuk berhasil menyelesaikan fungsi apa pun yang diberikan metode ini kepada pengguna objek untuk...

Jika ini merupakan "pengecualian", dalam ketiadaan pengguna dengan Id itu akan mencegah aplikasi untuk berhasil menyelesaikan fungsi apa pun yang dilakukannya, (Katakanlah kami membuat faktur untuk pelanggan yang telah kami kirimi produk ke ... ), maka situasi ini harus melempar ArgumentException (atau pengecualian khusus lainnya).

Jika pengguna yang hilang ok, (salah satu hasil normal potensial memanggil fungsi ini) maka kembalikan nol ....

EDIT: (untuk menanggapi komentar dari Adam di jawaban lain)

Jika aplikasi berisi beberapa proses bisnis, satu atau lebih yang membutuhkan Pengguna untuk menyelesaikan dengan sukses, dan satu atau lebih yang dapat diselesaikan dengan sukses tanpa pengguna, maka pengecualian harus dibuang lebih jauh ke tumpukan panggilan, lebih dekat ke tempat proses bisnis yang membutuhkan Pengguna memanggil utas eksekusi ini. Metode antara metode ini dan titik itu (di mana pengecualian dilemparkan) harus hanya berkomunikasi bahwa tidak ada pengguna (null, boolean, apa pun - ini adalah detail implementasi).

Tetapi jika semua proses dalam aplikasi membutuhkan pengguna, saya masih akan membuang pengecualian dalam metode ini ...

Saya pribadi akan mengembalikan nol, karena itulah yang saya harapkan lapisan DAL / Repositori untuk bertindak.

Jika tidak ada, jangan kembalikan apa pun yang dapat ditafsirkan sebagai berhasil mengambil objek, nullberfungsi dengan baik di sini.

Yang paling penting adalah konsisten di seluruh Lapisan DAL / Repos Anda, sehingga Anda tidak bingung bagaimana menggunakannya.

saya cenderung

• return nulljika id objek tidak ada saat itu tidak diketahui sebelumnya apakah itu harus ada.
• throwjika id objek tidak ada saat itu seharusnya ada.

Saya membedakan dua skenario ini dengan tiga jenis metode ini. Pertama:

Boolean TryGetSomeObjectById(Int32 id, out SomeObject o)
{
    if (InternalIdExists(id))
    {
        o = InternalGetSomeObject(id);

        return true;
    }
    else
    {
        return false;
    }
}

Kedua:

SomeObject FindSomeObjectById(Int32 id)
{
    SomeObject o;

    return TryGetObjectById(id, out o) ? o : null;
}

Ketiga:

SomeObject GetSomeObjectById(Int32 id)
{
    SomeObject o;

    if (!TryGetObjectById(id, out o))
    {
        throw new SomeAppropriateException();
    }

    return o;
}

Namun pendekatan lain melibatkan lewat objek callback atau delegasi yang akan beroperasi pada nilai. Jika nilai tidak ditemukan, panggilan balik tidak disebut.

public void GetUserById(Guid id, UserCallback callback)
{
    // Lookup user
    if (userFound)
        callback(userEntity);  // or callback.Call(userEntity);
}

Ini berfungsi dengan baik ketika Anda ingin menghindari cek nol di seluruh kode Anda, dan ketika tidak menemukan nilai bukan kesalahan. Anda juga dapat memberikan panggilan balik ketika tidak ada objek yang ditemukan jika Anda memerlukan pemrosesan khusus.

public void GetUserById(Guid id, UserCallback callback, NotFoundCallback notFound)
{
    // Lookup user
    if (userFound)
        callback(userEntity);  // or callback.Call(userEntity);
    else
        notFound(); // or notFound.Call();
}

Pendekatan yang sama menggunakan objek tunggal mungkin terlihat seperti:

public void GetUserById(Guid id, UserCallback callback)
{
    // Lookup user
    if (userFound)
        callback.Found(userEntity);
    else
        callback.NotFound();
}

Dari perspektif desain, saya sangat suka pendekatan ini, tetapi memiliki kelemahan membuat situs panggilan lebih besar dalam bahasa yang tidak dengan mudah mendukung fungsi kelas satu.

Kami menggunakan CSLA.NET, dan dibutuhkan pandangan bahwa pengambilan data yang gagal harus mengembalikan objek "kosong". Ini sebenarnya cukup menjengkelkan, karena menuntut konvensi memeriksa apakah obj.IsNewbukan obj == null.

Seperti poster sebelumnya yang disebutkan, nilai pengembalian nol akan menyebabkan kode gagal segera, mengurangi kemungkinan masalah siluman yang disebabkan oleh objek kosong.

Secara pribadi, saya pikir nulllebih elegan.

Ini adalah kasus yang sangat umum, dan saya terkejut bahwa orang-orang di sini tampaknya terkejut dengan hal itu: pada aplikasi web apa pun, data sering diambil menggunakan parameter querystring, yang jelas-jelas dapat dikacaukan, sehingga mengharuskan pengembang menangani insiden "tidak ditemukan" ".

Anda dapat menangani ini dengan:

if (User.Exists (id)) {
  this.User = User.Fetch (id);
} lain {
  Response.Redirect ("~ / notfound.aspx");
}

... tapi itu panggilan tambahan ke database setiap saat, yang mungkin menjadi masalah pada halaman dengan lalu lintas tinggi. Sedangkan:

this.User = User.Fetch (id);

if (this.User == null) {
  Response.Redirect ("~ / notfound.aspx");
}

... hanya membutuhkan satu panggilan.

Saya lebih suka null, karena kompatibel dengan operator null-coalescing ( ??).

Saya akan mengatakan return null bukan objek kosong.

Tetapi contoh spesifik yang telah Anda sebutkan di sini, Anda sedang mencari pengguna dengan id pengguna, yang merupakan semacam kunci untuk pengguna itu, dalam hal ini saya mungkin ingin melemparkan pengecualian jika tidak ada instance instance pengguna ditemukan .

Ini adalah aturan yang biasanya saya ikuti:

• Jika tidak ada hasil yang ditemukan pada pencarian dengan operasi kunci utama, lempar ObjectNotFoundException.
• Jika tidak ada hasil yang ditemukan pada pencarian dengan kriteria lain, kembalikan nol.
• Jika tidak ada hasil ditemukan pada penemuan dengan kriteria non-kunci yang dapat mengembalikan beberapa objek mengembalikan koleksi kosong.

Ini akan bervariasi berdasarkan konteks, tetapi saya umumnya akan mengembalikan nol jika saya mencari satu objek tertentu (seperti dalam contoh Anda) dan mengembalikan koleksi kosong jika saya mencari satu set objek tetapi tidak ada.

Jika Anda membuat kesalahan dalam kode Anda dan mengembalikan null mengarah ke pengecualian null pointer, maka semakin cepat Anda menangkap bahwa semakin baik. Jika Anda mengembalikan objek kosong, penggunaan awal mungkin berhasil, tetapi Anda mungkin mendapatkan kesalahan nanti.

Yang terbaik dalam hal ini mengembalikan "null" dalam kasus tidak ada pengguna tersebut. Jadikan metode Anda statis.

Edit:

Biasanya metode seperti ini adalah anggota beberapa kelas "Pengguna" dan tidak memiliki akses ke anggota contohnya. Dalam hal ini metode harus statis, jika tidak, Anda harus membuat turunan dari "Pengguna" dan kemudian memanggil metode GetUserById yang akan mengembalikan contoh "Pengguna" yang lain. Setuju ini membingungkan. Tetapi jika metode GetUserById adalah anggota dari beberapa kelas "DatabaseFactory" - tidak ada masalah untuk meninggalkannya sebagai anggota instance.

Saya pribadi mengembalikan instance default objek. Alasannya adalah bahwa saya mengharapkan metode untuk mengembalikan nol ke banyak atau nol ke satu (tergantung pada tujuan metode). Satu-satunya alasan bahwa itu akan menjadi keadaan kesalahan dalam bentuk apa pun, menggunakan pendekatan ini, adalah jika metode tidak mengembalikan objek (s) dan selalu diharapkan (dalam hal pengembalian satu ke banyak atau tunggal).

Adapun asumsi bahwa ini adalah pertanyaan domain bisnis - saya hanya tidak melihatnya dari sisi persamaan. Normalisasi tipe pengembalian adalah pertanyaan arsitektur aplikasi yang valid. Paling tidak, itu tunduk pada standardisasi dalam praktik pengkodean. Saya ragu bahwa ada pengguna bisnis yang akan mengatakan "dalam skenario X, beri mereka nol".

Di Objek Bisnis kami, kami memiliki 2 metode Get utama:

Untuk menjaga hal-hal sederhana dalam konteks atau Anda mempertanyakan mereka akan menjadi:

// Returns null if user does not exist
public UserEntity GetUserById(Guid userId)
{
}

// Returns a New User if user does not exist
public UserEntity GetNewOrExistingUserById(Guid userId)
{
}

Metode pertama digunakan ketika mendapatkan entitas tertentu, metode kedua digunakan secara khusus saat menambahkan atau mengedit entitas di halaman web.

Ini memungkinkan kita untuk memiliki yang terbaik dari kedua dunia dalam konteks di mana mereka digunakan.

Saya seorang mahasiswa IT Prancis, jadi permisi bahasa Inggris saya yang buruk. Di kelas kami, kami diberitahu bahwa metode seperti itu tidak boleh mengembalikan null, atau objek kosong. Pengguna metode ini seharusnya memeriksa dulu bahwa objek yang ia cari ada sebelum mencoba mendapatkannya.

Menggunakan Java, kami diminta untuk menambahkan assert exists(object) : "You shouldn't try to access an object that doesn't exist";di awal metode apa pun yang dapat mengembalikan nol, untuk mengekspresikan "prasyarat" (Saya tidak tahu apa kata dalam bahasa Inggris).

IMO ini benar-benar tidak mudah digunakan tetapi itulah yang saya gunakan, menunggu sesuatu yang lebih baik.

Jika kasus pengguna tidak ditemukan cukup sering muncul, dan Anda ingin mengatasinya dengan berbagai cara tergantung pada keadaan (kadang-kadang melemparkan pengecualian, kadang-kadang mengganti pengguna kosong) Anda juga bisa menggunakan sesuatu yang dekat dengan tipe F # Optionatau Haskell Maybe, yang secara eksplisit memisahkan case 'no value' dari 'found something!'. Kode akses basis data dapat terlihat seperti ini:

public Option<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 Option<UserEntity>.Nothing; 
 else
    return Option.Just(existingUserEntity);
}

Dan digunakan seperti ini:

Option<UserEntity> result = GetUserById(...);
if (result.IsNothing()) {
    // deal with it
} else {
    UserEntity value = result.GetValue();
}

Sayangnya, semua orang tampaknya menggulung tipe seperti ini sendiri.

Saya biasanya mengembalikan nol. Ini menyediakan mekanisme cepat dan mudah untuk mendeteksi jika ada sesuatu yang kacau tanpa membuang pengecualian dan menggunakan banyak mencoba / menangkap semua tempat.

Untuk tipe koleksi saya akan mengembalikan Koleksi Kosong, untuk semua tipe lainnya saya lebih suka menggunakan pola NullObject untuk mengembalikan objek yang mengimplementasikan antarmuka yang sama dengan tipe yang kembali. untuk perincian tentang pola, periksa tautan teks

Menggunakan pola NullObject ini akan menjadi: -

public UserEntity GetUserById(Guid userId)

{// Bayangkan beberapa kode di sini untuk mengakses basis data .....

 //Check if data was returned and return a null if none found
 if (!DataExists)
    return new NullUserEntity(); //Should I be doing this here instead? return new UserEntity();  
 else
    return existingUserEntity;

}

class NullUserEntity: IUserEntity { public string getFirstName(){ return ""; } ...} 

Untuk menempatkan apa yang orang lain katakan dengan cara empuk ...

Pengecualian untuk keadaan Luar Biasa

Jika metode ini adalah lapisan akses data murni, saya akan mengatakan bahwa mengingat beberapa parameter yang akan dimasukkan dalam pernyataan pilih, itu akan berharap bahwa saya mungkin tidak menemukan baris untuk membangun objek, dan karena itu mengembalikan nol akan dapat diterima karena ini adalah logika akses data.

Di sisi lain, jika saya mengharapkan parameter saya untuk mencerminkan kunci utama dan saya hanya akan mendapatkan satu baris kembali, jika saya mendapatkan lebih dari satu kembali saya akan melemparkan pengecualian. 0 ok untuk mengembalikan nol, 2 tidak.

Sekarang, jika saya memiliki beberapa kode masuk yang diperiksa terhadap penyedia LDAP kemudian diperiksa terhadap DB untuk mendapatkan detail lebih lanjut dan saya berharap itu harus disinkronkan setiap saat, saya mungkin akan melemparkan pengecualian itu. Seperti yang orang lain katakan, itu aturan bisnis.

Sekarang saya akan mengatakan itu adalah aturan umum . Ada saat-saat di mana Anda mungkin ingin memecahkannya. Namun, pengalaman dan percobaan saya dengan C # (banyak itu) dan Java (sedikit dari itu) telah mengajarkan saya bahwa jauh lebih mahal kinerja bijaksana untuk menangani pengecualian daripada menangani masalah yang dapat diprediksi melalui logika kondisional. Saya berbicara dengan nada 2 atau 3 kali lipat lebih mahal dalam beberapa kasus. Jadi, jika mungkin kode Anda bisa berakhir dalam satu lingkaran, maka saya akan menyarankan mengembalikan nol dan mengujinya.

Maafkan pseudo-php / code saya.

Saya pikir itu benar-benar tergantung pada tujuan penggunaan hasil.

Jika Anda bermaksud mengedit / memodifikasi nilai balik dan menyimpannya, maka kembalikan objek kosong. Dengan begitu, Anda bisa menggunakan fungsi yang sama untuk mengisi data pada objek baru atau yang sudah ada.

Katakanlah saya memiliki fungsi yang mengambil kunci utama dan array data, mengisi baris dengan data, lalu menyimpan catatan yang dihasilkan ke db. Karena saya bermaksud mengisi objek dengan data saya, itu bisa menjadi keuntungan besar untuk mendapatkan objek kosong kembali dari pengambil. Dengan begitu, saya bisa melakukan operasi yang identik dalam kedua kasus. Anda menggunakan hasil dari fungsi pengambil tidak peduli apa.

Contoh:

function saveTheRow($prim_key, $data) {
    $row = getRowByPrimKey($prim_key);

    // Populate the data here

    $row->save();
}

Di sini kita dapat melihat bahwa rangkaian operasi yang sama memanipulasi semua catatan jenis ini.

Namun, jika tujuan akhir dari nilai pengembalian adalah untuk membaca dan melakukan sesuatu dengan data, maka saya akan mengembalikan nol. Dengan cara ini, saya dapat dengan cepat menentukan apakah tidak ada data yang dikembalikan dan menampilkan pesan yang sesuai kepada pengguna.

Biasanya, saya akan menangkap pengecualian dalam fungsi saya yang mengambil data (jadi saya bisa mencatat pesan kesalahan, dll ...) lalu mengembalikan null langsung dari tangkapan. Secara umum tidak masalah bagi pengguna akhir apa masalahnya, jadi saya menemukan yang terbaik untuk merangkum kesalahan saya logging / pemrosesan secara langsung dalam fungsi yang mendapatkan data. Jika Anda mempertahankan basis kode bersama di perusahaan besar ini, ini sangat menguntungkan karena Anda dapat memaksa kesalahan logging / penanganan bahkan pada pemrogram yang paling malas sekalipun.

Contoh:

function displayData($row_id) {
    // Logging of the error would happen in this function
    $row = getRow($row_id);
    if($row === null) {
        // Handle the error here
    }

    // Do stuff here with data
}

function getRow($row_id) {
 $row = null;
 try{
     if(!$db->connected()) {
   throw excpetion("Couldn't Connect");
  }

  $result = $db->query($some_query_using_row_id);

  if(count($result) == 0 ) {
   throw new exception("Couldn't find a record!");
  }

  $row = $db->nextRow();

 } catch (db_exception) {
  //Log db conn error, alert admin, etc...
  return null; // This way I know that null means an error occurred
 }
 return $row;
}

Itu aturan umum saya. Sejauh ini sudah bekerja dengan baik.

Pertanyaan yang menarik dan saya pikir tidak ada jawaban "benar", karena selalu tergantung pada tanggung jawab kode Anda. Apakah metode Anda tahu apakah tidak ada data yang ditemukan bermasalah atau tidak? Dalam kebanyakan kasus, jawabannya adalah "tidak" dan itulah sebabnya mengembalikan nol dan membiarkan penelepon yang menangani situasinya sempurna.

Mungkin pendekatan yang baik untuk membedakan metode melempar dari metode null-return adalah dengan menemukan konvensi di tim Anda: Metode yang mengatakan mereka "mendapatkan" sesuatu harus melempar pengecualian jika tidak ada yang didapat. Metode yang mengembalikan null dapat dinamai berbeda, mungkin "Cari ..." sebagai gantinya.

Jika objek yang dikembalikan adalah sesuatu yang dapat diulangi, saya akan mengembalikan objek yang kosong, sehingga saya tidak perlu menguji nol terlebih dahulu.

Contoh:

bool IsAdministrator(User user)
{
    var groupsOfUser = GetGroupsOfUser(user);

    // This foreach would cause a run time exception if groupsOfUser is null.
    foreach (var groupOfUser in groupsOfUser) 
    {
        if (groupOfUser.Name == "Administrators")
        {
            return true;
        }
    }

    return false;
}

Saya suka tidak mengembalikan null dari metode apa pun, tetapi menggunakan tipe fungsional Option. Metode yang dapat mengembalikan tanpa hasil mengembalikan Opsi kosong, bukan nol.

Juga, metode seperti itu yang dapat mengembalikan tanpa hasil harus menunjukkan bahwa melalui nama mereka. Saya biasanya meletakkan Try atau TryGet atau TryFind di awal nama metode untuk menunjukkan bahwa ia dapat mengembalikan hasil yang kosong (misalnya TryFindCustomer, TryLoadFile, dll.).

Itu memungkinkan penelepon menerapkan teknik yang berbeda, seperti pipelining koleksi (lihat Koleksi Pipa Martin Fowler ) pada hasilnya.

Berikut adalah contoh lain di mana Opsi kembali bukan nol digunakan untuk mengurangi kompleksitas kode: Cara Mengurangi Kompleksitas Siklomatik: Opsi Jenis Fungsional

Lebih banyak daging untuk digiling: katakanlah DAL saya mengembalikan NULL untuk GetPersonByID seperti yang disarankan oleh beberapa orang. Apa yang harus saya lakukan (agak tipis) BLL jika menerima NULL? Lewati NULL itu dan biarkan konsumen akhir mengkhawatirkannya (dalam hal ini, halaman ASP.Net)? Bagaimana kalau BLL melempar pengecualian?

BLL dapat digunakan oleh ASP.Net dan Win App, atau perpustakaan kelas lainnya - Saya pikir tidak adil untuk mengharapkan konsumen akhir untuk secara intrinsik "tahu" bahwa metode GetPersonByID mengembalikan nol (kecuali jika jenis null digunakan, saya kira ).

Pandangan saya (untuk apa nilainya) adalah bahwa DAL saya mengembalikan NULL jika tidak ada yang ditemukan. UNTUK BEBERAPA BENDA, tidak apa-apa - bisa jadi 0: banyak daftar hal, jadi tidak punya barang apa-apa baik-baik saja (misalnya daftar buku favorit). Dalam hal ini, BLL saya mengembalikan daftar kosong. Untuk sebagian besar hal entitas tunggal (misalnya pengguna, akun, faktur) jika saya tidak memilikinya, maka itu jelas merupakan masalah dan membuang pengecualian yang mahal. Namun, melihat mengambil pengguna dengan pengidentifikasi unik yang sebelumnya diberikan oleh aplikasi harus selalu mengembalikan pengguna, pengecualian adalah pengecualian "tepat", karena di dalamnya luar biasa. Konsumen akhir BLL (ASP.Net, f'rinstance) hanya berharap hal-hal menjadi keren, sehingga Handler Exception Handler akan digunakan alih-alih membungkus setiap panggilan tunggal ke GetPersonByID dalam blok coba-tangkap.

Jika ada masalah mencolok dalam pendekatan saya, harap beri tahu saya karena saya selalu ingin belajar. Seperti yang dikatakan poster lainnya, pengecualian adalah hal yang mahal, dan pendekatan "memeriksa dulu" itu baik, tetapi pengecualian harus hanya itu - luar biasa.

Saya menikmati posting ini, banyak saran bagus untuk skenario "tergantung" :-)

Saya pikir fungsi tidak boleh mengembalikan nol, untuk kesehatan basis kode Anda. Saya dapat memikirkan beberapa alasan:

Akan ada sejumlah besar klausa penjaga yang memperlakukan referensi nol if (f() != null).

Apa itu null, apakah itu jawaban yang diterima atau masalah? Apakah null keadaan yang valid untuk objek tertentu? (bayangkan Anda adalah klien untuk kode). Maksud saya semua jenis referensi bisa nol, tetapi haruskah mereka?

Memiliki nullberkeliaran akan hampir selalu memberikan beberapa pengecualian NullRef tak terduga dari waktu ke waktu sebagai kode-dasar Anda tumbuh.

Ada beberapa solusi, tester-doer patternatau menerapkan option typepemrograman fungsional.

Saya bingung dengan jumlah jawaban (di seluruh web) yang mengatakan bahwa Anda memerlukan dua metode: metode "IsItThere ()" dan metode "GetItForMe ()" dan ini menyebabkan kondisi perlombaan. Apa yang salah dengan fungsi yang mengembalikan null, menugaskannya ke variabel, dan memeriksa variabel untuk Null semua dalam satu tes? Kode C lama saya dibumbui dengan

if (NULL! = (variabel = fungsi (argumen ...))) {

Jadi, Anda mendapatkan nilai (atau nol) dalam suatu variabel, dan hasilnya sekaligus. Apakah idiom ini dilupakan? Mengapa?

Saya setuju dengan sebagian besar posting di sini, yang cenderung ke arah null.

Alasan saya adalah bahwa menghasilkan objek kosong dengan properti yang tidak dapat dibatalkan dapat menyebabkan bug. Misalnya, entitas dengan int IDproperti akan memiliki nilai awal ID = 0, yang merupakan nilai yang sepenuhnya valid. Jika objek itu, dalam keadaan tertentu, disimpan ke database, itu akan menjadi hal yang buruk.

Untuk apa pun dengan iterator saya akan selalu menggunakan koleksi kosong. Sesuatu seperti

foreach (var eachValue in collection ?? new List<Type>(0))

adalah bau kode menurut saya. Properti koleksi tidak boleh nol, selamanya.

Kasing tepi adalah String. Banyak orang mengatakan, String.IsNullOrEmptytidak benar-benar diperlukan, tetapi Anda tidak selalu dapat membedakan antara string kosong dan null. Selain itu, beberapa sistem basis data (Oracle) tidak akan membedakan keduanya ( ''disimpan sebagai DBNULL), jadi Anda dipaksa untuk menanganinya secara merata. Alasannya adalah, sebagian besar nilai string berasal dari input pengguna atau dari sistem eksternal, sementara kotak teks atau sebagian besar format pertukaran tidak memiliki representasi berbeda untuk ''dan null. Jadi, bahkan jika pengguna ingin menghapus nilai, ia tidak bisa melakukan apa pun selain membersihkan kontrol input. Juga perbedaan nvarcharbidang database nullable dan non-nullable lebih dari dipertanyakan, jika DBMS Anda bukan oracle - bidang wajib yang memungkinkan''aneh, UI Anda tidak akan pernah mengizinkan ini, jadi kendala Anda tidak memetakan. Jadi jawabannya di sini, menurut saya adalah, menanganinya sama, selalu.

Mengenai pertanyaan Anda tentang pengecualian dan kinerja: Jika Anda melemparkan pengecualian yang tidak dapat Anda tangani sepenuhnya dalam logika program Anda, Anda harus membatalkan, pada titik tertentu, apa pun program Anda lakukan, dan meminta pengguna untuk mengulang apa pun yang baru saja ia lakukan. Dalam hal itu, penalti kinerja dari a catchadalah yang paling tidak perlu Anda khawatirkan - harus bertanya kepada pengguna adalah gajah di dalam ruangan (yang berarti merender ulang seluruh UI, atau mengirim beberapa HTML melalui internet). Jadi, jika Anda tidak mengikuti anti-pola " Aliran Program dengan Pengecualian ", jangan repot-repot, lemparkan saja jika itu masuk akal. Bahkan dalam kasus batas, seperti "Pengecualian Validasi", kinerja benar-benar tidak menjadi masalah, karena Anda harus bertanya kepada pengguna lagi, dalam hal apa pun.

Sebuah Pola Asynchronous TryGet:

Untuk metode sinkron, saya percaya @Johann Gerell ini jawabannya adalah yang pola untuk digunakan dalam semua kasus.

Namun pola TryGet dengan outparameter tidak berfungsi dengan metode Async.

Dengan Tuple Literals C # 7 sekarang Anda dapat melakukan ini:

async Task<(bool success, SomeObject o)> TryGetSomeObjectByIdAsync(Int32 id)
{
    if (InternalIdExists(id))
    {
        o = await InternalGetSomeObjectAsync(id);

        return (true, o);
    }
    else
    {
        return (false, default(SomeObject));
    }
}