MethodA, sırayla MethodC'yi çağıran bir MethodB'yi çağırır.

MethodB veya MethodC'de işlem istisnası yoktur. Ancak MethodA'da istisna kullanımı var.

MethodC'de bir istisna oluşur.

Şimdi, bu istisna, uygun şekilde işleyen Yöntem A'ya yansıyor.

Bundaki sorun ne?

Aklımda, bir noktada arayan bir kişi MetotB veya MetotC'yi yürütecek ve bu metotlarda istisnalar meydana geldiğinde, bu metotların istisnalarını ele almaktan ne kazanılacağı, esasen sadece denemek / yakalamak / nihayet bloklamaktır. onlar callee kadar kabarcık?

İstisna işlemeyle ilgili ifade veya fikir birliği, yürütmenin yalnızca bundan dolayı devam edemediği durumlarda bir istisnadır. Anladım. Fakat neden istisnayı yakalamamak yerine, zinciri sonuna kadar denemek / yakalamak için zincirleri daha fazla ilerletmiyorsunuz?

Kaynakları serbest bırakman gerektiğinde anlıyorum. Bu tamamen farklı bir konu.

Genel bir prensip olarak, onlarla ne yapacağınızı bilmiyorsanız istisnalar yakalamayın. MetodC bir istisna atarsa, ancak MetodB'nin bununla başa çıkması için yararlı bir yolu yoksa, istisnanın Metot A'ya yayılmasına izin vermelidir.

Bir yöntemin yakalama ve yeniden başlatma mekanizmasının olması için tek nedenler şunlardır:

• Bir istisnayı, yukarıdaki arayan için daha anlamlı olan farklı bir duruma dönüştürmek istiyorsunuz.
• İstisnaya ek bilgi eklemek istiyorsunuz.
• Biri olmadan sızdırılacak kaynakları temizlemek için bir toplama maddesine ihtiyacınız var.

Aksi takdirde, istisnaları yanlış seviyede yakalamak, çağıran koda (ve nihayetinde yazılımın kullanıcısına) herhangi bir geri bildirim vermeden sessizce başarısız olan bir kodla sonuçlanma eğilimindedir. Bir istisna yakalamanın ve ardından hemen yeniden incelemenin alternatifi anlamsızdır.

Bundaki sorun ne ?

Kesinlikle hiçbir şey.

Şimdi, bu istisna, uygun şekilde işleyen Yöntem A'ya yansıyor.

"uygun şekilde ele alır" önemli kısımdır. Yapılandırılmış İstisna İşleme'nin temel noktası budur.

Kodunuz bir İstisna ile "yararlı" bir şey yapabilirse, bunun için gidin. Değilse, o zaman rahat bırak.

. . . neden istisnayı yakalamamaya çalışıyorum, zincirleri tamamen denemek / yakalamak için bloklar yerine zinciri daha fazla.

Yapman gereken de tam olarak buydu . Eğer işleyiciyi / yeniden okuyucuyu "tamamen aşağı" olan bir kod okuyorsanız, o zaman muhtemelen oldukça zayıf bir kod okuyorsunuzdur.

Ne yazık ki, bazı Geliştiriciler catch bloklarını yalnızca yazdıkları her yönteme attıkları (punto amaçlı değil) yazdıkları "kazan plakası" kodu olarak görürler, çünkü çoğu zaman "gerçekten" almazlar. Bu İstisnalar "kaçmaz" ve programlarını öldürmez.

Buradaki zorluğun bir kısmı, çoğu zaman bu sorunun farkına bile varılmamasıdır, çünkü İstisnalar her zaman atılmamaktadır , ancak bunlar olduğunda , program çok fazla zaman harcar ve İstisna ile gerçekten yararlı bir şeyler yapan bir yere ulaşmak için çağrı yığınını yavaş yavaş açmak için çaba gösterme.

Kütüphaneler ve Uygulamalar arasında bir fark yaratmalısınız.

Kütüphaneler yakalanmamış istisnaları özgürce atabilir

Bir kütüphane tasarlarken, bir noktada neyin yanlış gidebileceğini düşünmeniz gerekir. Parametreler yanlış aralıkta olabilir veya nullharici kaynaklar kullanılamayabilir vs.

Kütüphaneniz en sık onlarla mantıklı bir şekilde başa çıkmak için bir yolu olmayacak . Mantıklı olan tek çözüm uygun bir İstisna atmak ve Uygulamanın geliştiricisinin onunla ilgilenmesine izin vermektir.

Uygulamalar her zaman bir noktada istisnalar yakalamalıdır

Bir İstisna yakalandığında, onları Hatalar veya Ölümcül Hatalar olarak sınıflandırmayı seviyorum . Düzenli bir Hata , Uygulamamdaki tek bir işlemin başarısız olduğu anlamına gelir. Örneğin, hedef yazılabilir olmadığı için açık bir belge kaydedilemedi. Uygulamanın yapması gereken tek mantıklı düşünce, kullanıcıyı işlemin başarıyla tamamlanamayacağı konusunda bilgilendirmek, sorunla ilgili insan tarafından okunabilir bilgiler vermek ve sonra kullanıcının ne yapması gerektiğine karar vermesine izin vermektir.

Bir Önemli Hata ana Uygulama mantığı kurtarmak değil bir hatadır. Örneğin, grafik aygıt sürücüsü bir video oyunda çöküyorsa, Uygulamanın kullanıcıyı "nezaketle" bilgilendirmesi mümkün değildir. Bu durumda, bir günlük dosyası yazılmalı ve mümkünse kullanıcı bir şekilde veya başka bir şekilde bilgilendirilmelidir.

Bu kadar ağır bir durumda bile, Başvuru bu İstisna'yı anlamlı bir şekilde ele almalıdır. Bu, bir Günlük dosyası yazmayı, Kilitlenme Raporu göndermeyi vb. İçerebilir. Uygulamanın İstisna'ya bir şekilde yanıt vermemesi için hiçbir sebep yoktur.

Tarif ettiğiniz modelde yanlış olan, A yönteminin üç senaryo arasında ayrım yapmanın bir yolu olmayacağıdır:

1. B Yöntemi beklenen şekilde başarısız oldu.

2. C Yöntemi, B Yöntemi tarafından beklenmeyen bir şekilde başarısız oldu, ancak B Yöntemi güvenli bir şekilde terk edilebilecek bir işlemi gerçekleştirirken başarısız oldu.

3. C Yöntemi, B Yöntemi tarafından beklenmeyen bir şekilde başarısız oldu, ancak B usulü, işleri B'nin C'nin başarısızlığı nedeniyle temizleyemediği geçici bir tutarsız duruma getirmeyen bir işlem gerçekleştirirken gerçekleştirdi.

A yönteminin bu senaryoları ayırt edebilmesi için tek yol, B'den atılan istisna, bu amaç için yeterli bilgi içeriyorsa ya da B yöntemi için serbest bırakılan yığın, nesnenin açıkça geçersiz kılınmış bir durumda kalmasına neden oluyorsa olacaktır . Ne yazık ki, istisna çerçevelerin çoğu her iki modeli de zorlaştırmakta, programcıları "daha az kötü" tasarım kararları almaya zorlamaktadır.