Haruskah saya memvalidasi nilai balik pemanggilan metode bahkan jika saya tahu bahwa metode tidak dapat mengembalikan input yang buruk?


30

Saya bertanya-tanya apakah saya harus mempertahankan nilai pengembalian pemanggilan metode dengan memvalidasi bahwa mereka memenuhi harapan saya, bahkan jika saya tahu bahwa metode yang saya panggil akan memenuhi harapan tersebut.

DIBERIKAN

User getUser(Int id)
{
    User temp = new User(id);
    temp.setName("John");

    return temp;
}

HARUS SAYA LAKUKAN

void myMethod()
{
    User user = getUser(1234);
    System.out.println(user.getName());
}

ATAU

void myMethod()
{
    User user = getUser(1234);

    // Validating
    Preconditions.checkNotNull(user, "User can not be null.");
    Preconditions.checkNotNull(user.getName(), "User's name can not be null.");

    System.out.println(user.getName());
}

Saya menanyakan hal ini pada level konseptual. Jika saya tahu cara kerja metode yang saya panggil. Entah karena saya menulisnya atau saya memeriksanya. Dan logika dari nilai yang mungkin dikembalikan memenuhi prasyarat saya. Apakah "lebih baik" atau "lebih tepat" untuk melewatkan validasi, atau haruskah saya masih mempertahankan nilai-nilai yang salah sebelum melanjutkan dengan metode yang saat ini saya laksanakan meskipun itu harus selalu berlalu.


Kesimpulan saya dari semua jawaban (jangan ragu untuk menjawab sendiri):

Tegaskan kapan
  • Metode ini telah menunjukkan perilaku buruk di masa lalu
  • Metode ini dari sumber yang tidak dipercaya
  • Metode ini digunakan dari tempat lain, dan tidak secara eksplisit menyatakan post-kondisi
Jangan nyatakan kapan:
  • Metode ini sesuai dengan Anda (lihat jawaban yang dipilih untuk detail)
  • Metode ini secara eksplisit mendefinisikan kontraknya dengan sesuatu seperti dokumen yang tepat, tipe keselamatan, uji unit, atau pemeriksaan pasca-kondisi
  • Kinerja sangat penting (dalam hal ini, mode debug mode dapat digunakan sebagai pendekatan hybrid)

1
Bertujuan untuk cakupan kode 100%!
Jared Burrows

9
Mengapa Anda berfokus pada satu masalah saja ( Null)? Mungkin sama bermasalahnya jika namanya ""(bukan null tetapi string kosong) atau "N/A". Entah Anda bisa mempercayai hasilnya, atau Anda harus paranoid dengan tepat.
MSalters

3
Dalam basis kode kami, kami memiliki skema penamaan: getFoo () berjanji untuk tidak mengembalikan nol, dan getFooIfPresent () dapat mengembalikan nol.
pjc50

Dari mana asalnya kode kewarasan Anda berasal? Apakah Anda mengasumsikan nilai akan selalu non-nol karena divalidasi pada entri, atau karena struktur yang digunakan untuk mengambil nilai? Dan, yang lebih penting, apakah Anda menguji setiap skenario kasus tepi yang mungkin? Termasuk kemungkinan skrip berbahaya?
Zibbobz

Jawaban:


42

Itu tergantung pada seberapa besar kemungkinan getUser dan myMethod berubah, dan yang lebih penting, seberapa besar kemungkinan mereka berubah secara independen satu sama lain .

Jika Anda entah bagaimana tahu pasti bahwa getUser tidak akan pernah, pernah, pernah berubah di masa depan, maka ya itu buang-buang waktu untuk memvalidasinya, sama seperti membuang-buang waktu memvalidasi yang imemiliki nilai 3 segera setelah i = 3;pernyataan. Pada kenyataannya, Anda tidak tahu itu. Tetapi ada beberapa hal yang Anda tahu:

  • Apakah kedua fungsi ini "hidup bersama"? Dengan kata lain, apakah mereka memiliki orang yang sama yang memeliharanya, apakah mereka bagian dari file yang sama, dan dengan demikian apakah mereka cenderung tetap "sinkron" satu sama lain? Dalam hal ini, Anda mungkin perlu menambahkan cek validasi, karena itu hanya berarti lebih banyak kode yang harus diubah (dan berpotensi memunculkan bug) setiap kali kedua fungsi berubah atau dire-refactored ke sejumlah fungsi yang berbeda.

  • Apakah fungsi getUser adalah bagian dari API yang terdokumentasi dengan kontrak tertentu, dan myMethod hanya klien dari API tersebut di basis kode lain? Jika demikian, Anda dapat membaca dokumentasi itu untuk mengetahui apakah Anda harus memvalidasi nilai kembali (atau pra-memvalidasi parameter input!) Atau apakah benar-benar aman untuk mengikuti secara membabi buta jalur bahagia. Jika dokumentasi tidak memperjelas hal ini, minta pengelola untuk memperbaikinya.

  • Akhirnya, jika fungsi khusus ini secara tiba-tiba dan tidak terduga mengubah perilakunya di masa lalu, dengan cara yang melanggar kode Anda, Anda memiliki hak untuk menjadi paranoid tentang hal itu. Bug cenderung mengelompok.

Perhatikan bahwa semua hal di atas berlaku bahkan jika Anda adalah penulis asli dari kedua fungsi tersebut. Kami tidak tahu apakah kedua fungsi ini diharapkan untuk "hidup bersama" selama sisa hidup mereka, atau apakah mereka perlahan-lahan akan terpisah menjadi modul-modul yang terpisah, atau jika Anda entah bagaimana menembak diri Anda sendiri di kaki dengan bug yang lebih tua versi getUser. Tapi Anda mungkin bisa menebak dengan cukup baik.


2
Juga: Jika Anda mengubahnya getUsernanti, sehingga bisa mengembalikan nol, akankah pemeriksaan eksplisit memberi Anda informasi yang tidak bisa Anda dapatkan dari "NullPointerException" dan nomor baris?
user253751

Tampaknya ada dua hal yang dapat Anda validasi: (1) Metode ini berfungsi dengan baik, karena tidak memiliki bug. (2) Bahwa metode tersebut menghormati kontrak Anda. Saya bisa melihat memvalidasi # 1 terlalu banyak. Anda seharusnya memiliki tes yang melakukan # 1 sebagai gantinya. Itulah sebabnya saya tidak akan memvalidasi i = 3 ;. Jadi pertanyaan saya berkaitan dengan # 2. Saya suka jawaban Anda untuk itu, tetapi pada saat yang sama, gunakan jawaban penilaian Anda. Apakah Anda melihat masalah lain yang timbul dari memvalidasi kontrak Anda secara eksplisit selain kemudian membuang-buang waktu untuk menulis pernyataan tersebut?
Didier A.

Satu-satunya "masalah" lainnya adalah jika interpretasi Anda terhadap kontrak itu salah, atau menjadi salah, maka Anda harus mengubah semua validasinya. Tapi itu berlaku untuk semua kode lain juga.
Ixrec

1
Tidak bisa melawan kerumunan. Jawaban ini jelas yang paling benar dalam meliput topik pertanyaan saya. Saya ingin menambahkan itu dari membaca semua jawaban, terutama @MikeNakis, saya sekarang berpikir Anda harus menegaskan pra-kondisi Anda, setidaknya dalam mode debug, ketika Anda memiliki salah satu dari dua poin terakhir dari Ixrec. Jika Anda dihadapkan dengan poin-poin pertama, maka mungkin diperlukan terlalu banyak untuk menegaskan prasyarat Anda. Akhirnya, dengan kontrak eksplisit, seperti dokumen yang tepat, keselamatan jenis, uji unit, atau pemeriksaan pasca-kondisi, Anda tidak boleh menyatakan prasyarat Anda, itu akan berlebihan.
Didier A.

22

Jawaban Ixrec baik, tetapi saya akan mengambil pendekatan yang berbeda karena saya percaya itu layak dipertimbangkan. Untuk tujuan diskusi ini saya akan berbicara tentang pernyataan, karena itulah nama yang Preconditions.checkNotNull()secara tradisional Anda ketahui.

Yang ingin saya sarankan adalah bahwa pemrogram sering melebih-lebihkan tingkat di mana mereka yakin bahwa sesuatu akan berperilaku dengan cara tertentu, dan meremehkan konsekuensi dari tidak berperilaku seperti itu. Juga, programmer sering tidak menyadari kekuatan asersi sebagai dokumentasi. Selanjutnya, dalam pengalaman saya, programmer menegaskan hal-hal yang jauh lebih jarang daripada seharusnya.

Moto saya adalah:

Pertanyaan yang harus selalu Anda tanyakan pada diri sendiri bukanlah "haruskah saya menegaskan hal ini?" tetapi "adakah yang saya lupa nyatakan?"

Tentu saja, jika Anda benar - benar yakin bahwa sesuatu berperilaku dengan cara tertentu, Anda akan menahan diri untuk menyatakan bahwa itu memang berperilaku seperti itu, dan itu sebagian besar masuk akal. Sangat tidak mungkin untuk menulis perangkat lunak jika Anda tidak dapat mempercayai apa pun.

Tetapi ada pengecualian bahkan untuk aturan ini. Anehnya, untuk mengambil contoh Ixrec, ada semacam situasi di mana sangat diinginkan untuk mengikuti int i = 3;dengan pernyataan yang imemang dalam kisaran tertentu. Ini adalah situasi di mana ikemungkinan akan diubah oleh seseorang yang mencoba berbagai skenario bagaimana-jika, dan kode yang mengikuti bergantung pada imemiliki nilai dalam rentang tertentu, dan tidak segera jelas dengan cepat melihat pada kode berikut apa kisaran yang dapat diterima adalah. Jadi, int i = 3; assert i >= 0 && i < 5;pada awalnya mungkin tampak tidak masuk akal, tetapi jika Anda memikirkannya, ia memberi tahu Anda bahwa Anda boleh bermain dengannya i, dan itu juga memberi tahu Anda kisaran di mana Anda harus tinggal. Pernyataan adalah jenis dokumentasi terbaik, karenaitu diberlakukan oleh mesin , jadi itu adalah jaminan yang sempurna, dan itu akan di refactored bersama-sama dengan kode , sehingga tetap relevan.

getUser(int id)Contoh Anda bukanlah kerabat konseptual yang sangat jauh dari assign-constant-and-assert-in-rangecontoh tersebut. Anda tahu, secara definisi, bug terjadi ketika sesuatu menunjukkan perilaku yang berbeda dari perilaku yang kami harapkan. Benar, kami tidak bisa menegaskan semuanya, jadi terkadang ada beberapa debugging. Tapi itu adalah fakta yang sudah mapan dalam industri bahwa semakin cepat kita menemukan kesalahan, semakin sedikit biayanya. Pertanyaan yang harus Anda ajukan tidak hanya seberapa yakin Anda bahwa Anda tidak getUser()akan pernah mengembalikan nol, (dan tidak pernah mengembalikan pengguna dengan nama nol,) tetapi juga, hal-hal buruk apa yang akan terjadi dengan sisa kode jika tidak Bahkan suatu hari mengembalikan sesuatu yang tidak terduga, dan betapa mudahnya dengan cepat melihat sisa kode untuk mengetahui dengan tepat apa yang diharapkan getUser().

Jika perilaku tak terduga akan menyebabkan database Anda menjadi korup, maka mungkin Anda harus menegaskan bahkan jika Anda 101% yakin itu tidak akan terjadi. Jika nullnama pengguna akan menyebabkan beberapa kesalahan aneh yang tidak dapat dilacak, ribuan baris lebih jauh ke bawah dan milyaran siklus jam kemudian, maka mungkin yang terbaik adalah gagal sedini mungkin.

Jadi, meskipun saya tidak setuju dengan jawaban Ixrec, saya menyarankan agar Anda dengan serius mempertimbangkan fakta bahwa pernyataan tidak ada biaya, jadi benar-benar tidak ada yang hilang, hanya untuk diperoleh, dengan menggunakannya secara bebas.


2
Iya nih. Tegaskan itu. Saya datang ke sini untuk memberikan kurang lebih jawaban ini. ++
RubberDuck

2
@ SeveJessop saya akan memperbaikinya ... && sureness < 1).
Mike Nakis

2
@ MikeNakis: itu selalu menjadi mimpi buruk ketika menulis unit test, nilai kembali yang diizinkan oleh antarmuka tetapi tidak mungkin untuk benar-benar menghasilkan dari input apa pun ;-) Bagaimanapun, ketika Anda 101% yakin Anda benar maka Anda pasti salah !
Steve Jessop

2
+1 untuk menunjukkan hal-hal yang saya benar-benar lupa sebutkan dalam jawaban saya.
Ixrec

1
@ DavidZ Itu benar, pertanyaan saya diasumsikan validasi run-time. Tetapi mengatakan Anda tidak percaya metode debug dan percaya pada prod adalah sudut pandang yang mungkin baik pada topik. Jadi gaya C menegaskan mungkin cara yang baik untuk menghadapi situasi ini.
Didier A.

8

Yang pasti tidak.

Seorang penelepon tidak boleh memeriksa apakah fungsi yang dihadapinya mematuhi kontraknya. Alasannya sederhana: ada banyak penelepon yang berpotensi dan itu tidak praktis dan bahkan bisa dibilang salah dari sudut pandang konseptual untuk setiap penelepon tunggal untuk menduplikasi logika untuk memeriksa hasil fungsi lainnya.

Jika ada pemeriksaan yang harus dilakukan, masing-masing fungsi harus memeriksa kondisi pasca sendiri. Post-conditions memberi Anda keyakinan bahwa Anda menerapkan fungsi dengan benar dan pengguna akan dapat mengandalkan kontrak fungsi Anda.

Jika fungsi tertentu tidak dimaksudkan untuk mengembalikan nol, maka ini harus didokumentasikan dan menjadi bagian dari kontrak fungsi itu. Inilah inti dari kontrak ini: menawarkan kepada pengguna beberapa invarian yang dapat mereka andalkan sehingga mereka menghadapi lebih sedikit rintangan saat menulis fungsi mereka sendiri.


Saya setuju dengan sentimen umum, tetapi ada situasi di mana masuk akal untuk memvalidasi nilai kembali. Misalnya jika Anda memanggil Layanan Web eksternal, Anda kadang-kadang ingin setidaknya memvalidasi format jawaban (xsd, dll ...)
AK_

Sepertinya Anda menganjurkan gaya Desain dengan Kontrak alih-alih Pemrograman Defensif. Saya pikir ini adalah jawaban yang bagus. Jika metode ini memiliki kontrak yang ketat, saya bisa mempercayainya. Dalam kasus saya tidak, tapi saya bisa mengubahnya untuk melakukannya. Katakan aku tidak bisa? Apakah Anda berpendapat bahwa saya harus memercayai implementasinya? Bahkan jika itu tidak secara eksplisit menyatakan dalam dokumen itu bahwa ia tidak mengembalikan nol, atau benar-benar memiliki pemeriksaan pasca-kondisi?
Didier A.

Menurut pendapat saya, Anda harus menggunakan penilaian terbaik Anda dan mempertimbangkan berbagai aspek seperti seberapa besar Anda memercayai penulis untuk melakukan hal yang benar, seberapa besar kemungkinan antarmuka fungsi berubah, dan seberapa ketat batasan waktu Anda. Yang sedang berkata, sebagian besar waktu, penulis fungsi memiliki ide yang cukup jelas tentang apa kontrak fungsi seharusnya, bahkan jika dia tidak mendokumentasikannya. Karena itu, saya katakan Anda harus memercayai penulis untuk melakukan hal yang benar dan hanya menjadi defensif ketika Anda tahu bahwa fungsinya tidak ditulis dengan baik.
Paul

Saya menemukan bahwa memercayai orang lain untuk melakukan hal yang benar membantu saya menyelesaikan pekerjaan lebih cepat. Yang sedang berkata, jenis aplikasi yang saya tulis mudah untuk diperbaiki ketika masalah terjadi. Seseorang yang bekerja dengan perangkat lunak yang lebih kritis terhadap keselamatan mungkin berpikir bahwa saya terlalu lunak dan lebih suka pendekatan yang lebih defensif.
Paul

5

Jika null adalah nilai balik yang valid dari metode getUser, maka kode Anda harus menanganinya dengan If, bukan Exception - itu bukan kasus luar biasa.

Jika null bukan nilai balik yang valid dari metode getUser, maka ada bug di getUser - metode getUser harus melempar pengecualian atau diperbaiki.

Jika metode getUser adalah bagian dari pustaka eksternal atau tidak dapat diubah dan Anda ingin pengecualian dilemparkan dalam kasus pengembalian nol, bungkus kelas dan metode untuk melakukan pemeriksaan dan melempar pengecualian sehingga setiap instance dari panggilan untuk getUser konsisten dalam kode Anda.


Null bukan nilai balik getUser yang valid. Dengan memeriksa getUser, saya melihat bahwa implementasi tidak akan pernah mengembalikan nol. Pertanyaan saya adalah, apakah saya harus mempercayai inspeksi saya dan tidak memeriksa metode saya, atau haruskah saya meragukan inspeksi saya, dan masih memiliki cek. Mungkin juga perubahan metode di masa depan, melanggar harapan saya untuk tidak mengembalikan nol.
Didier A.

Dan bagaimana jika perubahan getUser atau user.getName untuk membuang pengecualian? Anda harus memiliki cek, tetapi bukan sebagai bagian dari metode menggunakan Pengguna. Bungkus metode getUser - dan bahkan kelas Pengguna - untuk menegakkan kontrak Anda, jika Anda khawatir tentang perubahan di masa depan terhadap pemecahan kode getUser. Juga buat unit test untuk memeriksa asumsi Anda tentang perilaku kelas.
MatthewC

@didibus Untuk memparafrasekan jawaban Anda ... Sebuah emotikon smiley bukan nilai balik getUser yang valid. Dengan memeriksa getUser, saya melihat bahwa implementasinya tidak akan pernah mengembalikan emotikon smiley . Pertanyaan saya adalah, apakah saya harus mempercayai inspeksi saya dan tidak memeriksa metode saya, atau haruskah saya meragukan inspeksi saya, dan masih memiliki cek. Mungkin juga metode ini berubah di masa depan, mematahkan harapan saya untuk tidak mengembalikan emoticon yang tersenyum . Bukan tugas penelepon untuk mengkonfirmasi bahwa fungsi yang dipanggil memenuhi kontraknya.
Vince O'Sullivan

@ VinceO'Sullivan Sepertinya "kontrak" adalah pusat dari masalah ini. Dan pertanyaan saya adalah tentang kontrak implisit, versus eksplisit. Metode yang mengembalikan int Saya tidak akan menyatakan bahwa saya tidak mendapatkan string. Tetapi, jika saya hanya menginginkan int positif, bukan? Hanya tersirat bahwa metode ini tidak mengembalikan int negatif, karena saya memeriksanya. Tidak jelas dari tanda tangan atau dokumentasi yang tidak.
Didier A.

1
Tidak masalah apakah kontraknya implisit atau eksplisit. Bukan tugas kode panggilan untuk memvalidasi bahwa metode yang dipanggil mengembalikan data yang valid ketika diberikan data yang valid. Dalam contoh Anda, Anda tahu bahwa init negatif bukan jawaban yang salah tetapi apakah Anda tahu apakah int positif benar? Berapa banyak tes yang benar-benar Anda butuhkan, untuk membuktikan bahwa metode ini berfungsi? Satu-satunya jalan yang benar adalah dengan menganggap bahwa metode itu benar.
Vince O'Sullivan

5

Saya berpendapat bahwa premis pertanyaan Anda tidak aktif: mengapa menggunakan referensi nol untuk memulai?

The Pola nol objek adalah cara untuk kembali benda-benda yang pada dasarnya melakukan apa-apa: "tidak ada pengguna" daripada kembali null untuk pengguna Anda, mengembalikan objek yang mewakili

Pengguna ini akan tidak aktif, memiliki nama kosong, dan nilai-nilai non-nol lainnya yang menunjukkan "tidak ada di sini." Manfaat utama adalah Anda tidak perlu membuang sampah sembarangan karena program Anda akan membatalkan pemeriksaan, mencatat, dll. Anda hanya menggunakan objek Anda.

Mengapa algoritma harus peduli dengan nilai nol? Langkah-langkahnya harus sama. Sangat mudah dan jauh lebih jelas untuk memiliki objek nol yang mengembalikan nol, string kosong, dll.

Berikut ini adalah contoh dari pemeriksaan kode untuk null:

User u = getUser();
String displayName = "";
if (u != null) {
  displayName = u.getName();
}
return displayName;

Berikut adalah contoh kode menggunakan objek nol:

return getUser().getName();

Mana yang lebih jelas? Saya percaya yang kedua adalah.


Sementara pertanyaan tersebut ditandai , perlu dicatat bahwa pola objek nol benar - benar berguna dalam C ++ saat menggunakan referensi. Referensi Java lebih seperti pointer C ++, dan memungkinkan null. Referensi C ++ tidak dapat menampung nullptr. Jika seseorang ingin memiliki sesuatu yang analog dengan referensi nol di C ++, pola objek nol adalah satu-satunya cara yang saya tahu untuk mencapainya.


Null hanyalah contoh dari apa yang saya tegaskan. Bisa jadi saya membutuhkan nama yang tidak kosong. Pertanyaan saya masih berlaku, apakah Anda akan memvalidasi itu? Atau bisa berupa sesuatu yang mengembalikan int, dan saya tidak dapat memiliki int negatif, atau harus dalam kisaran yang diberikan. Jangan menganggapnya sebagai masalah nol per katakan.
Didier A.

1
Mengapa metode mengembalikan nilai yang salah? Satu-satunya tempat yang harus diperiksa adalah pada batas aplikasi Anda: antarmuka dengan pengguna dan dengan sistem lain. Kalau tidak, itu sebabnya kami memiliki pengecualian.

Bayangkan saya punya: int i = getCount; float x = 100 / i; Jika saya tahu getCount tidak mengembalikan 0, karena saya menulis metode atau memeriksanya, haruskah saya melewatkan cek untuk 0?
Didier A.

@didibus: Anda dapat melewati pemeriksaan jika getCount() mendokumentasikan jaminan bahwa itu tidak kembali 0, dan tidak akan melakukannya di masa depan kecuali dalam keadaan di mana seseorang memutuskan untuk membuat perubahan yang melanggar dan terus memperbarui semua yang memanggilnya untuk mengatasi antarmuka baru. Melihat apa yang dilakukan kode saat ini tidak membantu, tetapi jika Anda akan memeriksa kode maka kode yang akan diperiksa adalah unit test getCount(). Jika mereka mengujinya untuk tidak mengembalikan 0, maka Anda tahu setiap perubahan di masa depan untuk mengembalikan 0 akan dianggap sebagai perubahan melanggar karena tes akan gagal.
Steve Jessop

Tidak jelas bagi saya bahwa objek nol lebih baik daripada null. Bebek nol dapat berdetak, tetapi itu bukan bebek - pada kenyataannya, secara semantik, ini adalah kebalikan dari bebek. Setelah Anda memperkenalkan objek nol, kode apa pun yang menggunakan kelas itu mungkin harus memeriksa apakah salah satu objeknya adalah objek nol - misalnya Anda memiliki null sesuatu dalam set, berapa banyak hal yang Anda miliki? Bagi saya ini seperti cara untuk menunda kegagalan dan mengaburkan kesalahan. Artikel yang ditautkan secara khusus memperingatkan untuk tidak menggunakan objek nol "hanya untuk menghindari cek nol dan membuat kode lebih mudah dibaca".
sdenham

1

Secara umum, saya akan mengatakan bahwa itu terutama tergantung pada tiga aspek berikut:

  1. kekokohan: dapatkah metode pemanggilan mengatasi nullnilai? Jika suatu nullnilai mungkin menghasilkan RuntimeExceptionsaya akan merekomendasikan cek - kecuali kompleksitas rendah dan metode yang dipanggil / dipanggil dibuat oleh penulis yang sama, dan nulltidak diharapkan (misalnya keduanya privatedalam paket yang sama).

  2. tanggung jawab kode: jika pengembang A bertanggung jawab untuk getUser()metode ini, dan pengembang B menggunakannya (misalnya sebagai bagian dari perpustakaan), saya sangat merekomendasikan untuk memvalidasi nilainya. Hanya karena pengembang B mungkin tidak tahu tentang perubahan yang menghasilkan nullnilai pengembalian potensial .

  3. kompleksitas: semakin tinggi kompleksitas keseluruhan dari program atau lingkungan, semakin saya akan merekomendasikan untuk memvalidasi nilai kembali. Bahkan jika Anda merasa yakin bahwa hari ini tidak mungkin nulldalam konteks metode pemanggilan, mungkin Anda harus mengubah getUser()kasus penggunaan lain. Setelah beberapa bulan atau tahun berlalu, dan ribuan baris kode telah ditambahkan, ini bisa menjadi jebakan.

Selain itu, saya akan merekomendasikan untuk mendokumentasikan nullnilai pengembalian potensial dalam komentar JavaDoc. Karena menyoroti deskripsi JavaDoc di sebagian besar IDE, ini bisa menjadi peringatan bermanfaat bagi siapa pun yang menggunakan getUser().

/** Returns ....
  * @param: id id of the user
  * @return: a User instance related to the id;
  *          null, if no user with identifier id exists
 **/
User getUser(Int id)
{
    ...
}

-1

Anda tentu tidak perlu.

Misalnya, jika Anda sudah tahu bahwa pengembalian tidak akan pernah menjadi nol - Mengapa Anda ingin menambahkan cek nol? Menambahkan cek nol tidak akan merusak apa pun tetapi itu hanya berlebihan. Dan lebih baik tidak kode logika yang berlebihan selama Anda bisa menghindarinya.


1
Saya tahu, tetapi hanya karena saya memeriksa atau menulis implementasi metode lain. Kontrak metode tidak secara eksplisit mengatakan bahwa itu tidak bisa. Jadi itu bisa, misalnya, berubah di masa depan. Atau bisa saja ada bug yang menyebabkan null kembali meskipun ia berusaha untuk tidak melakukannya.
Didier A.
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.