Haruskah jenis pengecualian yang digunakan kembali disukai daripada yang digunakan tunggal?

Katakanlah saya memiliki Doors yang dikelola oleh DoorService. The DoorServicebertanggung jawab atas pembukaan, menutup dan mengunci pintu yang disimpan di database.

public interface DoorService
{
    void open(Door door) throws DoorLockedException, DoorAlreadyOpenedException;

    void close(Door door) throws DoorAlreadyClosedException;

    /**
     * Closes the door if open
     */
    void lock(Door door) throws DoorAlreadyLockedException;
}

Untuk metode kunci, ada a DoorAlreadyLockedExceptiondan untuk metode terbuka ada a DoorLockedException. Ini adalah opsi tetapi ada opsi lain yang memungkinkan:

1) Gunakan DoorLockedExceptionuntuk semuanya, agak canggung ketika menangkap pengecualian pada lock()panggilan

try
{
    doorService.lock(myDoor);
}
catch(DoorLockedException ex) // door ALREADY locked
{
    //error handling...
}

2) Memiliki 2 jenis pengecualian DoorLockedExceptiondanDoorAlreadyLockedException

3) Memiliki 2 tipe pengecualian tetapi biarkan DoorAlreadyLockedException extends DoorLockedException

Solusi mana yang terbaik dan mengapa?

Saya tahu orang-orang membuat masalah besar menggunakan pengecualian untuk kontrol aliran tapi itu bukan masalah terbesar di sini. Saya melihat pelanggaran pemisahan permintaan perintah besar . Tetapi itu pun bukan yang terburuk.

Tidak, yang terburuk ada di sini:

/**
 * Closes the door if open
 */

Kenapa segalanya meledak jika asumsi Anda tentang keadaan pintu salah tetapi lock()hanya memperbaikinya untuk Anda? Lupa bahwa ini membuat tidak mungkin untuk mengunci pintu terbuka, yang sangat mungkin dan sesekali berguna. Tidak masalah di sini adalah Anda telah mencampur dua filosofi yang berbeda untuk berurusan dengan asumsi yang salah. Itu membingungkan. Jangan lakukan itu. Tidak pada tingkat abstraksi yang sama dengan gaya penamaan yang sama. Ow! Bawa salah satu ide itu ke luar. Metode layanan pintu semua harus bekerja dengan cara yang sama.

Adapun pelanggaran Pemisahan Permintaan Perintah saya tidak harus mencoba untuk menutup pintu untuk mencari tahu apakah itu ditutup atau terbuka. Aku seharusnya bisa bertanya. Layanan pintu tidak menyediakan cara untuk melakukan itu tanpa mungkin mengubah keadaan pintu. Itu membuat ini jauh lebih buruk daripada perintah yang juga terjadi untuk mengembalikan nilai (kesalahpahaman umum tentang apa CQS tentang). Di sini, perintah perubahan negara adalah satu-satunya cara untuk melakukan kueri! Ow!

Adapun pengecualian lebih mahal daripada kode status, itu pembicaraan optimasi. Cukup cepat cukup cepat. Tidak masalah sebenarnya adalah bahwa manusia tidak mengharapkan pengecualian untuk kasus tipikal. Anda dapat berdebat tentang apa yang paling Anda sukai. Bagi saya pertanyaan besarnya adalah seberapa mudah Anda membuat kode menggunakan.

ensureClosed(DoorService service, Door door){
  // Need door closed and unlocked. No idea of its state. What to do?
  try {
    service.open(door)
    service.close(door)
  } 
  catch( DoorLockedException e ){
    //Have no way to unlock the door so give up and die
    log(e);
    throw new NoOneGaveMeAKeyException(e);      
  }
  catch( DoorAlreadyOpenedException e ){
    try { 
      service.close(door);
    }
    catch( DoorAlreadyClosedException e ){
      //Some multithreaded goof has been messing with our door.
      //Oh well, this is what we wanted anyway.
      //Hope they didn't lock it.
    }
  }
}

Tolong jangan buat saya menulis kode seperti ini. Tolong beri kami isLocked()dan isClosed()metode. Dengan itu saya bisa menulis sendiri ensureClosed()dan ensureUnlocked()metode yang mudah dibaca. Yang hanya membuang jika kondisi pos mereka dilanggar. Saya lebih suka menemukan Anda sudah menulis dan mengujinya tentu saja. Hanya saja, jangan mencampurnya dengan yang melempar ketika mereka tidak dapat mengubah negara. Paling tidak beri mereka nama yang berbeda.

_{Apa pun yang Anda lakukan, tolong jangan panggil apa pun tryClose(). Itu nama yang mengerikan.}

Adapun DoorLockedExceptionsendirian vs juga DoorAlreadyLockedExceptionsakit mengatakan ini: ini semua tentang menggunakan kode. Tolong jangan merancang layanan seperti ini tanpa menulis kode menggunakan dan melihat kekacauan yang Anda buat. Refactor dan mendesain ulang sampai menggunakan kode setidaknya dapat dibaca. Bahkan, pertimbangkan untuk menulis menggunakan kode terlebih dahulu.

ensureClosed(DoorService service, Door door){
  if( !service.isClosed(door) ){
    try{
      service.close(door);
    }
    catch( DoorAlreadyClosedException e ){
      //Some multithreaded goof has been messing with our door.
      //Oh well, this is what we wanted anyway.
      //Hope they didn't lock it.
    }
  } else {
    //This is what you wanted, so quietly do nothing. 
    //Why are you even here? Who bothers to write empty else conditions?
  }
}

ensureUnlocked(DoorService service, Door door){
  if( service.islocked(door) ){
    throw new NoOneGaveMeAKeyException(); 
  }
}

Membuat perbedaan antara DoorLockedExceptiondan DoorAlreadyLockedExceptionmenyarankan bahwa berbagai jenis pengecualian sedang digunakan untuk kontrol aliran, praktik yang sudah secara luas dianggap sebagai antipattern.

Memiliki beberapa tipe pengecualian untuk sesuatu yang tidak berbahaya ini gratis. Kompleksitas tambahan tidak sebanding dengan manfaat tambahan.

Cukup gunakan DoorLockedExceptionuntuk semuanya.

Lebih baik lagi, lakukan saja. Jika pintu sudah terkunci, maka masih akan dalam kondisi yang benar ketika lock()metode selesai. Jangan melempar pengecualian untuk kondisi yang biasa-biasa saja.

Jika Anda masih merasa tidak nyaman dengan itu, ubah nama metode Anda ensureDoorLocked().

Subjek dari pertanyaan ini "Haruskah jenis pengecualian daur ulang lebih disukai daripada yang digunakan sekali pakai?" tampaknya telah diabaikan, tidak hanya dalam jawaban, tetapi dalam perincian untuk pertanyaan (jawabannya adalah untuk perincian pertanyaan).

Saya setuju dengan sebagian besar kritik terhadap kode yang ditawarkan responden.

Tetapi sebagai jawaban untuk pertanyaan utama, saya akan mengatakan bahwa Anda harus lebih suka menggunakan kembali 'pengecualian daur ulang' daripada 'penggunaan tunggal'.

Dalam penggunaan penanganan pengecualian yang lebih umum, Anda memiliki JARAK yang luar biasa dalam kode antara tempat pengecualian terdeteksi dan dibuang, dan di mana pengecualian ditangkap dan ditangani. Itu berarti menggunakan tipe pribadi (modular) dalam penanganan pengecualian pada umumnya tidak akan berfungsi dengan baik. Program tipikal dengan penanganan pengecualian - akan memiliki beberapa lokasi tingkat atas dalam kode di mana pengecualian ditangani. Dan karena itu adalah lokasi tingkat atas, sulit bagi mereka untuk memiliki pengetahuan terperinci tentang aspek-aspek sempit dari modul tertentu.

Sebaliknya, mereka kemungkinan akan memiliki penangan tingkat tinggi untuk beberapa masalah tingkat tinggi.

Satu-satunya alasan menggunakan kelas pengecualian kustom terperinci tampaknya masuk akal dalam sampel Anda, adalah karena (dan di sini saya membayangi responden lain) - Anda tidak boleh menggunakan penanganan pengecualian untuk aliran kontrol biasa.

Alternatif yang belum dijelajahi. Anda mungkin memodelkan hal yang salah dengan kelas Anda, bagaimana jika Anda memiliki ini?

public interface OpenDoor
{
    public ClosedDoor close();
    public LockedDoor lock();
}

public interface ClosedDoor
{
    public OpenDoor open();
    public LockedDoor lock();
}

public interface LockedDoor
{
    // ? unlock? open?
}

Sekarang tidak mungkin untuk mencoba sesuatu yang merupakan kesalahan. Anda tidak memerlukan pengecualian.

Saya akan menjawab pertanyaan asli, daripada mengkritik contohnya.

Sederhananya, jika Anda berharap bahwa klien mungkin perlu bereaksi berbeda untuk setiap kasus, itu menjamin jenis pengecualian baru.

Jika Anda memutuskan untuk menggunakan beberapa jenis pengecualian dan Anda masih berharap bahwa klien dalam beberapa kasus ingin membuat klausa tangkapan umum untuk mereka, Anda mungkin harus membuat superclass abstrak yang mereka berdua kembangkan.

Ini pseudocode tapi saya pikir Anda akan mendapatkan apa yang saya maksud:

public interface DoorService
{
    // ensures the door is open, uses key if locked, returns false if lock without a key or key does not fit
    bool Open(Door door, optional Key key) throws DoorStuckException, HouseOnFireException;

    // closes the door if open. already closed doors stay closed. Locked status does not change.
    void Close(Door door) throws throws DoorStuckException, HouseOnFireException;

    // closes the door if open and locks it
    void CloseAndLock(Door door, Key key) throws DoorStuckException, HouseOnFireException;
}

Ya, penggunaan kembali jenis pengecualian masuk akal, jika Anda menggunakan pengecualian untuk hal-hal yang benar-benar luar biasa . Karena hal-hal yang benar-benar luar biasa sebagian besar masalah lintas sektoral. Anda menggunakan Pengecualian pada dasarnya untuk aliran kontrol dan itu mengarah ke masalah tersebut.