İstisna yönetimi kesişen bir konu mu?

İstisna işleme ve oturum açma kaygıları arasında, her ikisinin de birbiriyle kesişen endişeler olduğunu fark etmiyorum. Ne düşünüyorsun? Bir yöntemin uyguladığı çekirdek mantık ile serpiştirilmekten ziyade ayrı ayrı ele alınmamalı mı?

EDIT : Söylemeye çalışıyorum, bence bir yöntem uygulaması sadece başarılı yürütme yolu için mantık içermeli ve istisnalar başka bir yerde ele alınmasıdır. Bu, işaretli / işaretsiz istisnalar ile ilgili değildir.

Örneğin, bir dil, aşağıdaki gibi yapıları kullanarak istisnaları tam olarak denetlenmiş bir şekilde işleyebilir:

class FileReader {

  public String readFile(String path) {
    // implement the reading logic, avoid exception handling
  }

}

handler FileReader {

   handle String readFile(String path) {
      when (IOException joe) {
        // somehow access the FileInputStram and close it
      }
   }

}

Yukarıdaki kavramsal dilde, FileReader işleyicinin yokluğunda program derlenmez , çünkü FileReader sınıfın readFile öğesi istisnayı atmaz. Böylece derleyici FileReader işleyiciyi bildirerek işlenmesini ve programın derlenmesini sağlayabilir.

Bu şekilde hem kontrol edilmiş hem de kontrol edilmemiş istisna problemlerinden en iyisine sahibiz: sağlamlık ve okunabilirlik.

Bazı durumlarda evet

Eğer (hemen hemen her zaman olduğunu varsayalım) günlüğe kaydetmek istediğiniz bir istisna olduğu durumlarda, o zaman evet istisna bir çapraz kesim endişeye bağlıdır.

Çoğu zaman hayır

Ancak, bir soket dinleyicisi bağlantıyı bırakan diğer uç nedeniyle bir istisna atarsa, SocketListener örneğini alın, bu beklenen davranış olmalıdır ve bu nedenle uygulama istisnaya neden olan koşullara göre hareket etmelidir. Bu, genel bir Unsurun ele alması gereken bir şey değildir ve bu nedenle de kesişen bir konu olmamalıdır.

Kesişen bir konuyu belirleme

Aynı kodu tekrar tekrar çoğaltıyorsanız, bu kodun soyutlanması gerekir. Eğer soyutlama kendini birden fazla katmana yükseltirse, bu kesişen bir sorun olabilir. Ancak o zaman dikkate alınmalıdır.

Günlük kaydı isteğe bağlıdır. İstisnaları ele almak değil.

Günlüğe kaydetme oldukça geneldir ve belirli bir mantıktan kaynaklanırken genel bir tüketiciye beslenir. İstisnalar her zaman mantığa özgüdür ve bu mantık hakkında bilgili bazı kodlar, yaptığı karışıklığı işlemek zorundadır.

En azından ikisini sınırlı kullanımımda, bu iki hedefin aynı tasarım şemsiyesi altında değil, en iyi şekilde farklı şekillerde ele alındığı anlamına geliyor.

İstisna işlemeyi, belirli istisna türleri için kesişen bir endişe olarak görüyorum. Yalnızca acil arama kodunun doğru işleyebileceği yerel istisnalar vardır. Bir sorgu yürütmeye çalışırken örnek bir veritabanı istisnası olabilir. Ancak daha küresel olarak ele alınması gereken ve ele alınması gereken istisnalar da vardır. Güvenlik kimlik bilgilerinin olmamasıyla ilgili bir istisna olabilir (kullanıcıyı tekrar oturum açmaya zorlayın). Veya en azından, bir özel durumun daha özel bir koddan geçmesi durumunda, kullanıcıya BT'yi veya bunun gibi bir şeyi yeniden başlatmak veya bir günlük göndermek için ne yapmaları gerektiğini açıklamak için küresel bir işleyiciye ihtiyacınız vardır. Bu tür küresel olarak ele alınan istisnalar için kesişen bir konudur.

Bence bu, sızdıran soyutlamalar konusuna bağlanıyor.

Birçok istisna, soyutlama katmanları boyunca yayıldıkça yakalanmalı ve yeniden ele alınmalıdır. Yeniden atma, istisnayı, yeniden atmayı yapan soyutlamaya uygun yeni bir biçimde atmalıdır, böylece arayüzün bir parçası olarak mantıklıdır. Başka bir deyişle, daha düşük soyutlama seviyelerinden istisnalar, mevcut soyutlama formuna çevrilmelidir, böylece daha yüksek soyutlama seviyeleri, yalnızca istisna yönetimi için bile, daha düşük seviyeler hakkında bilgi sahibi olmak zorunda kalmaz.

Ancak, "sızdıran soyutlamalar ilkesi" bir konudur. Bazı istisnalar, bir sonraki soyutlama katmanında mantıklı olan bir forma çevrilemez.

Ağ bağlantılı bir dosya sistemi istisnası basit bir örnektir. Bir ağ hatası, bir "dosya" soyutlamasına mantıklı gelen terimlerle ifade edilemez veya eğer varsa soyutlama, dosya işlemenin uygulanmasıyla ilgili tüm ayrıntıları tamamen soyutlamamıştır.

Bu nedenle bir ağ hatası temel ağ soyutlamasından sızar ve bu nedenle kodun geri kalanında kesişen bir sorun olmalıdır.

Ancak bu istisnalara özgü değildir. Dosya soyutlamaları için gerçekte dosya soyutlamasıyla ilgili olmayan tüm bu dönüş değeri hata kodları, bunun yerine ayrıntı sabit diski veya ağı veya hataları ne olursa olsun farklı bir biçimde aynı şeydir, bu da sabit disk arızaları ve ağ arızaları anlamına gelir vs bu hataların nasıl rapor edildiğine bakılmaksızın kesişen endişelerdir.