Koddaki çalışma zamanı istisnalarını işlemek iyi bir uygulama değil mi?

Bir Java uygulaması üzerinde çalışıyorum ve Çalışma zamanı istisnalarının birçok yerde işlendiğini görüyorum. Örneğin,

try {
    // do something
} catch(NullPointerException e) {
    return null;
}

Sorularım, Çalışma Zamanı istisnalarını işlemek ne zaman iyi bir uygulamadır? İstisnalar ne zaman ele alınmamalıdır?

Değişir.

Örneğin , sağlanan dize ayrıştırılamazsa (bir RTE olan) Integer#parseIntatar NumberFormatException. Ancak, uygulamanızın yalnızca kullanıcı tamsayılar için olan bir metin alanına "x" yazdığı için kilitlenmesini istemiyor musunuz? İlk önce ayrıştırmaya çalışmadığınız sürece dizenin ayrıştırılıp ayrıştırılamayacağını nasıl anlarsınız? Bu durumda, RTE sadece bir tür hata mesajına neden olması gereken bir hata sinyalidir. Bunun kontrol edilmiş bir istisna olması gerektiği söylenebilir, ancak ne yapabilirsiniz - değil.

NullPointerExceptions genellikle eksik bir boş denetimin işaretidir. Bu nedenle, bu şekilde yakalamak yerine, istisnayı atmadığınızdan emin olmak için uygun null kontrolü eklemelisiniz.

Ancak bazen RunTimeExceptions ile çalışmak uygun olur. Örneğin, uygun yere boş denetim eklemek için kodu değiştiremediğinizde veya özel durum bir NullPointerException dışında bir şey olduğunda.

İstisnaları ele alma örneğiniz korkunç. Bunu yaptığınızda, yığın izlemesini ve sorunla ilgili kesin bilgileri kaybedersiniz. Ve muhtemelen başka bir NullPointerException'ı farklı bir yerde tetikleyeceğiniz ve ne olduğu ve nasıl çözüleceği hakkında yanıltıcı bilgiler alacağınız için çözmüyorsunuz.

Beklediğim istisnaları beklediğim yerde hallederim. (DB okuma / yazma hataları gibi). Beklenmedik istisnalar patlar. Başka bir yerde istisna bekliyor olabilir ve bunun mantığı olabilir.

İstisnalar sadece .. istisnalar olmalıdır. İstisnaları kullanırken en iyi uygulama, bunları olmasını beklediğiniz şeyin aksine bir durumun ortaya çıkması için kullanmaktır. Klasik örnek, bir dosya orada olmadığında atılan FileNotFoundException'dır. Dosyanın varlığını test ediyorsanız, bir şeye çarpıp çarpmadığınızı görmek için sadece 10 ayaklık bir çubukla prodding yaptığınızdan File.exists () kullanırsınız.

Teknik olarak aynı sonuçları bir deneme yakalamasında sararak ve dosyayı varmış gibi kullanarak başarabilirsiniz, ancak A) istisnalar genellikle kaynak açısından zordur ve B) programcılar dosyanın varsa var olduğunu düşündüğünüzü varsayarlar. bir programın genel karışıklığına katkıda bulunan bir try catch.

Bir veritabanından bazı değer getiren bir yöntem yazacağım birçok durum vardır. Bin şey yanlış gidebilir ve sadece küçük bir bilgiye nasıl ihtiyacım olduğunu görünce, 5 farklı istisna içeren bir deneme yakalama listesi ile çağrıyı çevrelemek uygun değildir. Yani, getirme yönteminde istisnalar yakalayacağım. Bir şeyler ters giderse, veritabanı bağlantısını veya nihayet yan tümcesinde neyi kapatmak ve null değerini döndürmek için uygun eylemi gerçekleştiririm. Bu sadece kodunuzu basitleştirdiği için değil, aynı zamanda "null" ifadesinin bir istisnadan almış olabileceğiniz aynı mesajı gönderdiği için bir şey planlandığı gibi gitmediği için iyi bir uygulamadır. Getirme yönteminde istisna özelliklerini yönetin, ancak işler yapmadığında ne yapacağınızı yönetin '

Örneğin:

Integer getUserCount() {
   Integer result = null;
   try {
      // Attempt to open database and retrieve data
   } catch (TimeoutException e) {
      logger.error("Got a watch?");
   } catch (MissingDatabaseException e) {
      logger.error("What are you smoking?");
   } catch (PermissionsToReadException e) {
      logger.error("Did you *really* think you were getting away with that?");
   } catch (PressedSendButtonToHardException e) {
      logger.error("Seriously.. just back away from the computer... slowly..");
   } catch (WTFException e) {
      logger.error("You're on your own with this one.. I don't even know what happened..");
   } finally {
      // Close connections and whatnot
   }
   return result;
}

void doStuff() {
   Integer result = getUserCount();
   if(result != null) {
       // Went as planned..
   }
}

evet doğru kullanım, çalışma zamanı istisnaları iyi bir uygulama değildir. nedeni pahalı / bellek yoğun olarak kabul edilir.