Apakah melempar RuntimeExceptions baru ke dalam kode yang tidak terjangkau merupakan gaya yang buruk?

Saya ditugaskan untuk memelihara aplikasi yang ditulis beberapa waktu lalu oleh pengembang yang lebih terampil. Saya menemukan potongan kode ini:

public Configuration retrieveUserMailConfiguration(Long id) throws MailException {
        try {
            return translate(mailManagementService.retrieveUserMailConfiguration(id));
        } catch (Exception e) {
            rethrow(e);
        }
        throw new RuntimeException("cannot reach here");
    }

Saya ingin tahu apakah melempar RuntimeException("cannot reach here")dibenarkan. Saya mungkin kehilangan sesuatu yang jelas mengetahui bahwa kode ini berasal dari kolega yang lebih berpengalaman.
EDIT: Ini adalah badan rethrow yang beberapa jawaban disebut. Saya menganggap itu tidak penting dalam pertanyaan ini.

private void rethrow(Exception e) throws MailException {
        if (e instanceof InvalidDataException) {
            InvalidDataException ex = (InvalidDataException) e;
            rethrow(ex);
        }
        if (e instanceof EntityAlreadyExistsException) {
            EntityAlreadyExistsException ex = (EntityAlreadyExistsException) e;
            rethrow(ex);
        }
        if (e instanceof EntityNotFoundException) {
            EntityNotFoundException ex = (EntityNotFoundException) e;
            rethrow(ex);
        }
        if (e instanceof NoPermissionException) {
            NoPermissionException ex = (NoPermissionException) e;
            rethrow(ex);
        }
        if (e instanceof ServiceUnavailableException) {
            ServiceUnavailableException ex = (ServiceUnavailableException) e;
            rethrow(ex);
        }
        LOG.error("internal error, original exception", e);
        throw new MailUnexpectedException();
    }


private void rethrow(ServiceUnavailableException e) throws
            MailServiceUnavailableException {
        throw new MailServiceUnavailableException();
    }

private void rethrow(NoPermissionException e) throws PersonNotAuthorizedException {
    throw new PersonNotAuthorizedException();
}

private void rethrow(InvalidDataException e) throws
        MailInvalidIdException, MailLoginNotAvailableException,
        MailInvalidLoginException, MailInvalidPasswordException,
        MailInvalidEmailException {
    switch (e.getDetail()) {
        case ID_INVALID:
            throw new MailInvalidIdException();
        case LOGIN_INVALID:
            throw new MailInvalidLoginException();
        case LOGIN_NOT_ALLOWED:
            throw new MailLoginNotAvailableException();
        case PASSWORD_INVALID:
            throw new MailInvalidPasswordException();
        case EMAIL_INVALID:
            throw new MailInvalidEmailException();
    }
}

private void rethrow(EntityAlreadyExistsException e)
        throws MailLoginNotAvailableException, MailEmailAddressAlreadyForwardedToException {
    switch (e.getDetail()) {
        case LOGIN_ALREADY_TAKEN:
            throw new MailLoginNotAvailableException();
        case EMAIL_ADDRESS_ALREADY_FORWARDED_TO:
            throw new MailEmailAddressAlreadyForwardedToException();
    }
}

private void rethrow(EntityNotFoundException e) throws
        MailAccountNotCreatedException,
        MailAliasNotCreatedException {
    switch (e.getDetail()) {
        case ACCOUNT_NOT_FOUND:
            throw new MailAccountNotCreatedException();
        case ALIAS_NOT_FOUND:
            throw new MailAliasNotCreatedException();
    }
}

Pertama, terima kasih telah memperkirakan pertanyaan Anda dan menunjukkan kepada kami apa yang rethrowbisa. Jadi, sebenarnya, apa yang dilakukannya adalah mengubah pengecualian dengan properti menjadi kelas pengecualian yang lebih halus. Lebih lanjut tentang ini nanti.

Karena saya tidak benar-benar menjawab pertanyaan utama pada awalnya, ini dia: ya, umumnya gaya buruk untuk melempar pengecualian runtime dalam kode yang tidak terjangkau; Anda sebaiknya menggunakan pernyataan, atau bahkan lebih baik, menghindari masalah. Seperti yang sudah ditunjukkan, kompiler di sini tidak dapat memastikan bahwa kode tidak pernah keluar dari try/catchblok. Anda dapat memperbaiki kode Anda dengan memanfaatkan ...

Kesalahan adalah nilai

^{(Tidak mengherankan, itu terkenal di mana saja )}

Mari kita gunakan contoh yang lebih sederhana, yang saya gunakan sebelum edit: jadi bayangkan Anda mencatat sesuatu dan membuat pengecualian wrapper seperti dalam jawaban Konrad . Sebut saja logAndWrap.

Alih-alih melempar pengecualian sebagai efek samping logAndWrap, Anda bisa membiarkannya bekerja sebagai efek samping dan membuatnya mengembalikan pengecualian (setidaknya, yang diberikan dalam input). Anda tidak perlu menggunakan obat generik, hanya fungsi dasar:

private Exception logAndWrap(Exception exception) {
    // or whatever it actually does
    Log.e("Ouch! " + exception.getMessage());
    return new CustomWrapperException(exception);
}

Kemudian, Anda dengan throwjelas, dan kompiler Anda senang:

try {
     return translate(mailManagementService.retrieveUserMailConfiguration(id));
} catch (Exception e) {
     throw logAndWrap(e);
}

Bagaimana jika Anda lupa throw?

Seperti dijelaskan dalam komentar Joe23 , cara pemrograman defensif untuk memastikan bahwa pengecualian selalu dilontarkan akan terdiri dari melakukan secara eksplisit throw new CustomWrapperException(exception)pada akhir logAndWrap, seperti yang dilakukan oleh Guava . Dengan begitu, Anda tahu bahwa pengecualian akan dilempar, dan penganalisa tipe Anda senang. Namun, pengecualian khusus Anda harus berupa pengecualian yang tidak dicentang, yang tidak selalu memungkinkan. Juga, saya menilai risiko pengembang hilang untuk menulis throwmenjadi sangat rendah: pengembang harus melupakannya dan metode sekitarnya tidak boleh mengembalikan apa pun, jika tidak kompiler akan mendeteksi pengembalian yang hilang. Ini adalah cara yang menarik untuk melawan sistem tipe, dan itu berhasil.

Rethrow

Sebenarnya rethrowdapat ditulis sebagai fungsi juga, tapi saya punya masalah dengan implementasinya saat ini:

• Ada banyak gips yang tidak berguna seperti Pemain sebenarnya diperlukan (lihat komentar):

  if (e instanceof ServiceUnavailableException) {
      ServiceUnavailableException ex = (ServiceUnavailableException) e;
      rethrow(ex);
  }
  

• Saat melempar / mengembalikan pengecualian baru, yang lama dibuang; dalam kode berikut, a MailLoginNotAvailableExceptiontidak mengizinkan saya untuk mengetahui login mana yang tidak tersedia, yang tidak nyaman; selain itu, stacktraces tidak akan lengkap:

  private void rethrow(EntityAlreadyExistsException e)
      throws MailLoginNotAvailableException, MailEmailAddressAlreadyForwardedToException {
      switch (e.getDetail()) {
          case LOGIN_ALREADY_TAKEN:
              throw new MailLoginNotAvailableException();
          case EMAIL_ADDRESS_ALREADY_FORWARDED_TO:
              throw new MailEmailAddressAlreadyForwardedToException();
      }
  }
  

• Mengapa kode asal tidak melempar pengecualian khusus itu di tempat pertama? Saya menduga bahwa rethrowini digunakan sebagai lapisan kompatibilitas antara subsistem (pengiriman) dan logika bisnis (mungkin tujuannya adalah untuk menyembunyikan detail implementasi seperti pengecualian yang dilemparkan dengan menggantinya dengan pengecualian khusus). Bahkan jika saya setuju bahwa akan lebih baik memiliki kode bebas-tangkap, seperti yang disarankan dalam jawaban Pete Becker , saya tidak berpikir Anda akan memiliki kesempatan untuk menghapus catchdan rethrowkode di sini tanpa refactoring besar.

rethrow(e);Fungsi ini melanggar prinsip yang mengatakan bahwa dalam keadaan normal, suatu fungsi akan kembali, sementara dalam keadaan luar biasa, suatu fungsi akan melempar pengecualian. Fungsi ini melanggar prinsip ini dengan melemparkan pengecualian dalam keadaan normal. Itulah sumber dari semua kebingungan.

Compiler mengasumsikan bahwa fungsi ini akan kembali dalam keadaan normal, sehingga sejauh yang bisa dikompilasi oleh kompiler, eksekusi dapat mencapai akhir dari retrieveUserMailConfigurationfungsi, di mana saat itu merupakan kesalahan untuk tidak memiliki returnpernyataan. The RuntimeExceptiondilemparkan ada seharusnya meringankan kekhawatiran ini dari kompilator, tetapi merupakan cara yang agak kikuk melakukannya. Cara lain untuk mencegah function must return a valuekesalahan adalah dengan menambahkan return null; //to keep the compiler happypernyataan, tapi itu juga sama kikuk menurut saya.

Jadi, secara pribadi, saya akan mengganti ini:

rethrow(e);

dengan ini:

report(e); 
throw e;

atau, lebih baik lagi, (seperti yang disarankan coredump ,) dengan ini:

throw reportAndTransform(e);

Dengan demikian, aliran kontrol akan dibuat jelas bagi kompiler, sehingga tugas akhir Anda throw new RuntimeException("cannot reach here");tidak hanya menjadi berlebihan, tetapi sebenarnya bahkan tidak dapat dikompilasi, karena akan ditandai oleh kompiler sebagai kode yang tidak dapat dijangkau.

Itu cara yang paling elegan dan sebenarnya juga paling sederhana untuk keluar dari situasi buruk ini.

The throwmungkin ditambahkan untuk berkeliling "metode harus kembali nilai" kesalahan yang mungkin terjadi - aliran data Java analyzer cukup cerdas untuk memahami bahwa tidak ada returnperlu setelah throw, tapi tidak setelah kustom Anda rethrow()metode, dan tidak ada @NoReturnpenjelasan yang bisa Anda gunakan untuk memperbaikinya.

Namun demikian, membuat Pengecualian baru dalam kode yang tidak terjangkau tampaknya berlebihan. Saya hanya akan menulis return null, mengetahui bahwa hal itu, pada kenyataannya, tidak pernah terjadi.

Itu

throw new RuntimeException("cannot reach here");

pernyataan menjelaskan kepada PERSON yang membaca kode apa yang terjadi, jadi jauh lebih baik daripada mengembalikan nol misalnya. Ini juga memudahkan untuk debug jika kode diubah dengan cara yang tidak terduga.

Namun rethrow(e)sepertinya salah! Jadi dalam kasus Anda, saya pikir refactoring kode adalah pilihan yang lebih baik. Lihat jawaban lain (saya suka coredump terbaik) untuk cara memilah kode Anda.

Saya tidak tahu apakah ada konvensi.

Bagaimanapun, trik lain adalah dengan melakukannya:

private <T> T rethrow(Exception exception) {
    // or whatever it actually does
    Log.e("Ouch! " + exception.getMessage());
    throw new CustomWrapperException(exception);
}

Mengizinkan ini:

try {
     return translate(mailManagementService.retrieveUserMailConfiguration(id));
} catch (Exception e) {
     return rethrow(e);
}

Dan tidak RuntimeExceptionperlu lagi buatan . Meskipun rethrowtidak pernah benar-benar mengembalikan nilai apa pun, itu cukup baik untuk kompiler sekarang.

Itu mengembalikan nilai dalam teori (metode tanda tangan), dan kemudian itu dibebaskan dari benar-benar melakukannya karena ia melempar pengecualian.

Ya, itu mungkin terlihat aneh, tapi sekali lagi - melempar hantu RuntimeException, atau mengembalikan nol yang tidak akan pernah terlihat di dunia ini - itu juga bukan keindahan.

Berusaha keras agar mudah dibaca, Anda dapat mengganti nama rethrowdan memiliki sesuatu seperti:

} catch (Exception e) {
     return nothingJustRethrow(e);
}

Jika Anda menghapus tryblok sepenuhnya maka Anda tidak perlu rethrowatau throw. Kode ini melakukan hal yang persis sama dengan aslinya:

public Configuration retrieveUserMailConfiguration(Long id) throws MailException {
    return translate(mailManagementService.retrieveUserMailConfiguration(id));
}

Jangan biarkan fakta bahwa itu berasal dari pengembang yang lebih berpengalaman menipu Anda. Ini adalah kode yang membusuk, dan ini terjadi setiap saat. Perbaiki saja.

EDIT: Saya salah membaca rethrow(e)karena hanya melemparkan kembali pengecualian e. Jika rethrowmetode itu benar-benar melakukan sesuatu selain melemparkan kembali pengecualian, maka menyingkirkannya memang mengubah semantik metode ini.