Ulaşılamaz kodda yeni RuntimeExceptions yazmak kötü bir stil midir?

Bir süre önce daha yetenekli geliştiriciler tarafından yazılmış bir uygulamayı sürdürmek için görevlendirildim. Bu kod parçasına rastladım:

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

Fırlatmanın RuntimeException("cannot reach here")haklı olup olmadığını merak ediyorum . Muhtemelen bu kod parçasının daha deneyimli meslektaşlardan geldiğini bilen bir şeyi özlüyorum.
EDIT: İşte bazı cevapların değinildiği tekrar vücut. Bu soruda önemli olmadığını düşündüm.

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

İlk olarak, sorunuzu çözdüğünüz ve bize ne yaptığını gösterdiğiniz için teşekkür ederiz rethrow. Yani aslında, yaptığı şey, istisnaları istisnalarla birlikte daha fazla özel durum sınıflarına dönüştürmektir. Bunun üzerine daha sonra.

Aslında asıl soruya aslında cevap vermediğim için, işte burada: evet, çalışma zamanı istisnalarını erişilemez kodda atmak genellikle kötü bir stildir; iddiaları kullansanız daha iyi, hatta problemden kaçınmalısınız. Daha önce de belirtildiği gibi, buradaki derleyici kodun hiçbir zaman try/catchbloktan çıkmadığından emin olamaz . Bundan yararlanarak kodunuzu yeniden değerlendirebilirsiniz ...

Hatalar değerlerdir

^{(Şaşırtıcı olmayan bir şekilde, halindeyken iyi bilinir )}

Düzenlemenizden önce kullandığım basit bir örneği kullanalım: bu yüzden bir şeyi kaydettiğinizi ve Konrad'ın cevabında olduğu gibi bir sarıcı istisnası oluşturduğunuzu hayal edin . Hadi diyelim logAndWrap.

İstisnaları bir yan etki olarak atmak yerine logAndWrap, işini bir yan etki olarak yapmasına izin verebilir ve bir istisna döndürmesini sağlayabilirsiniz (en azından girişte verilen). Jenerik kullanmanız gerekmez, sadece temel fonksiyonlar:

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

Öyleyse, throwaçıkça ve derleyiciniz mutludur:

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

Ya unutursan throw?

Joe23'ün yorumunda açıklandığı gibi , istisnanın her zaman atıldığından emin olmak için bir savunma programlama yolu açıkça birthrow new CustomWrapperException(exception) Guava.ThrowableslogAndWrap tarafından yapıldığı gibi sonun yapılmasından ibarettir . Bu şekilde, istisnanın atılacağını bilirsiniz ve tip analizörünüz mutludur. Bununla birlikte, özel istisnalarınızın her zaman mümkün olmayan kontrolsüz istisnalar olması gerekir. Ayrıca, bir geliştiricinin yazma riskini throwçok düşük olması için derecelendiririm : geliştirici bunu unutmalı ve çevreleyen yöntem hiçbir şey döndürmemelidir, aksi takdirde derleyici eksik bir dönüş tespit eder. Bu, tip sistemiyle savaşmanın ilginç bir yoludur ve yine de işe yarıyor.

rethrow

Gerçek rethrowde bir işlev olarak yazılabilir, ancak şu anki uygulamasında sorun yaşıyorum:

• Gibi birçok yararsız yayın var Aslında yayınlar gereklidir (yorumlara bakınız):

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

• Yeni istisnalar atarken / geri gönderirken, eskisi atılır; Aşağıdaki kodda, MailLoginNotAvailableExceptionhangi girişin uygun olmadığını, hangisinin uygunsuz olduğunu bilmeme izin vermez; dahası, yığınlar eksik olacak:

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

• Kaynak kod, neden bu özel istisnaları ilk başta atmıyor? Bunun rethrowbir (postalama) alt sistemi ve iş mantığı mantığı arasında bir uyum katmanı olarak kullanıldığından şüpheleniyorum (belki de amaç, atılan istisnalar gibi uygulama detaylarını özel istisnalar ile değiştirerek gizlemektir). Pete Becker'in cevabında önerildiği gibi, serbest kodun daha iyi olacağı konusunda hemfikir olsam bile , buradaki catchve rethrowbüyük çaplı yeniden yapılandırmalar olmadan kodu kaldırma fırsatınız olacağını sanmıyorum .

Bu rethrow(e);fonksiyon, normal şartlar altında bir fonksiyonun geri döneceğini, istisnai şartlar altında bir fonksiyonun istisna atacağını söyleyen prensibi ihlal eder. Bu işlev normal koşullarda bir istisna atarak bu prensibi ihlal eder. Tüm karışıklığın kaynağı bu.

Derleyici bu işlevin normal koşullar altında döneceğini varsayar, derleyicinin söyleyebildiği kadarıyla, yürütme retrieveUserMailConfigurationişlevin sonuna ulaşabilir, bu noktada bir returnifadeye sahip olmamak bir hatadır . RuntimeExceptionOrada derleyici bu endişeyi hafifletmek için gerekiyordu, ama bunu yapmanın oldukça aksak bir yoldur atılmış. function must return a valueHatayı önlemenin bir başka yolu da bir return null; //to keep the compiler happyifade eklemek , ancak bence eşit derecede zor.

Yani, şahsen, bunun yerine:

rethrow(e);

Bununla:

report(e); 
throw e;

veya, daha iyisi, ( coredump'un önerdiği gibi) şununla:

throw reportAndTransform(e);

Böylece, kontrolün akışı derleyiciye açıklık kazandıracak, yani finaliniz throw new RuntimeException("cannot reach here"); açıklık kazandıracak, sadece gereksiz olmayacak, hatta derleyici tarafından erişilemez kod olarak işaretleneceğinden derlenmeyecek hale gelecekti.

Bu çirkin durumdan kurtulmanın en zarif ve en basit yolu budur.

throwMuhtemelen yoksa ortaya çıkabilecek hata "bir değer döndürmesi gerekir yöntemi" almak için eklendi - Java veri analiz hayır olduğunu anlamak için akıllı yeterlidir akış returnbir sonraki gereklidir throw, ancak özel sonrasında rethrow()yöntemle ve hiçbir orada @NoReturnaçıklama Bunu düzeltmek için kullanabileceğini.

Bununla birlikte, ulaşılamaz kodda yeni bir İstisna oluşturmak gereksiz görünüyor. return nullAslında, asla olmadığını asla bilerek yazdım .

The

throw new RuntimeException("cannot reach here");

İfade bir KİŞİSELİ açıkça ortaya koyar olanları okuyan , bu nedenle örneğin null döndürmek çok daha iyidir. Ayrıca, kodun beklenmeyen şekilde değişmesi durumunda hata ayıklamayı kolaylaştırır.

Ancak rethrow(e)sadece yanlış görünüyor! Yani sizin durumunuzda kodu yeniden düzenlemenin daha iyi bir seçenek olduğunu düşünüyorum. Kodunuzu çözmenin yollarını öğrenmek için diğer cevaplara (coredump'ın en iyisini severim) bakın.

Bir kongre var mı bilmiyorum.

Her neyse, başka bir numara da böyle yapmak olacaktır:

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

Bunun için izin vermek:

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

Ve artık yapay RuntimeExceptiongerekmiyor. rethrowAsla herhangi bir değer vermese de , şimdi derleyici için yeterince iyi.

Teoride bir değer döndürür (yöntem imzası) ve sonra bunun yerine bir istisna atarken aslında yapmaktan muaftır.

Evet, garip görünebilir, ama sonra tekrar - bir hayalet atmak RuntimeExceptionya da bu dünyada hiç görülmeyecek şekilde boşa dönmek - bu da tam bir güzellik meselesi değil.

Okunabilirlik için çabalıyorsanız, yeniden adlandırabilir rethrowve şöyle bir şey olabilir:

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

tryBloğu tamamen çıkarırsanız , rethrowveya veya 'ye ihtiyacınız olmaz throw. Bu kod tam olarak orijinal ile aynı şeyi yapar:

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

Daha deneyimli geliştiricilerin geldiği gerçeğinin sizi aldatmasına izin vermeyin. Bu kod çürümesi ve her zaman olur. Sadece tamir et.

EDIT: Ben rethrow(e)sadece istisna yeniden atma olarak yanlış okudum e. Bu rethrowyöntem aslında istisnayı yeniden atmaktan başka bir şey yaparsa, ondan kurtulmak bu yöntemin anlamını değiştirir.