Genel istisnaları yakalamak gerçekten kötü bir şey midir?

Genellikle çoğu kod analizi uyarısına katılıyorum ve bunlara uymaya çalışıyorum. Ancak bununla daha zor zamanlar geçiriyorum:

CA1031: Genel istisna türlerini yakalamayın

Bu kuralın gerekçesini anlıyorum. Ancak uygulamada, atılan istisnadan bağımsız olarak aynı işlemi yapmak istersem, neden her birini özel olarak ele alacağım? Ayrıca, belirli istisnaları ele alırsam, aradığım kod gelecekte yeni bir istisna oluşturmak üzere değişirse ne olur? Şimdi bu yeni istisnayı ele almak için kodumu değiştirmem gerekiyor. Oysa basitçe yakaladıysam Exceptionkodumu değiştirmek zorunda değilsin.

Örneğin, Foo Bar'ı çağırırsa ve Foo'nun Bar tarafından atılan istisna türünden bağımsız olarak işlemeyi durdurması gerekiyorsa, yakaladığım istisna türüne özgü olmanın herhangi bir avantajı var mı?

Belki daha iyi bir örnek:

public void Foo()
{
    // Some logic here.
    LogUtility.Log("some message");
}

public static void Log()
{
    try
    {
        // Actual logging here.
    }
    catch (Exception ex)
    {
        // Eat it. Logging failures shouldn't stop us from processing.
    }
}

Burada genel bir istisna yakalamazsanız, mümkün olan her türlü istisnayı yakalamanız gerekir. Patrick'in OutOfMemoryExceptionbu şekilde ele alınmaması gereken iyi bir noktası var . Peki ya istisnaları görmezden gelmek istersem ama OutOfMemoryException?

Bu kurallar genellikle iyi bir fikirdir ve bu nedenle takip edilmelidir.

Ancak bunların genel kurallar olduğunu unutmayın. Tüm durumları kapsamıyorlar. En yaygın durumları kapsarlar. Belirli bir durumunuz varsa ve tekniğinizin daha iyi olduğu argümanını yapabilirseniz (ve bunu yapmak için argümanınızı ifade etmek için kodda bir yorum yazabilmelisiniz) sonra yapın (ve ardından hakem değerlendirmesini yapın).

Argümanın karşı tarafında.

Yukarıdaki örneğinizi, bunun için iyi bir durum olarak görmüyorum. Kayıt sistemi arızalıysa (muhtemelen başka bir istisna kaydı varsa), o zaman uygulamanın devam etmesini istemiyorum. Kullanıcının ne olduğunu görebilmesi için istisnadan çıkın ve çıktıya yazdırın.

Evet, genel istisnaları yakalamak kötü bir şey. İstisna, genellikle programın istediğinizi yapamayacağı anlamına gelir.

Başa çıkabileceğiniz birkaç istisna türü vardır :

• Ölümcül istisnalar : bellek yetersiz, yığın taşması, vb. Durumu iyileştiremezsin bu yüzden vazgeç
• İstisna atılan istisna çünkü kullandığınız koddaki hatalar : Bunları ele almaya çalışmayın, sorunun kaynağını düzeltin. Akış kontrolü için istisnalar kullanmayın
• İstisnai durumlar : Bu durumlarda sadece istisna durumlarını ele alın. Buraya şunları ekleyebiliriz: ağ kablosu takılı değil, internet bağlantısı çalışmıyor, izinler eksik.

Oh, ve genel bir kural olarak: Eğer bir istisna ile ne yapacağınızı bilmiyorsanız, hızlı bir şekilde başarısız olmanız daha iyi olur (istisnayı arayan kişiye iletin ve halletmesine izin verin).

En üstteki dış döngü, hepsini basabilmek için bunlardan birine sahip olmalı ve daha sonra korkunç, şiddetli ve NOISY ölümü (bu olmamalı ve birinin duyması gerektiği gibi) ölmelidir.

Aksi takdirde, genel büyük olasılıkla gibi çok dikkatli olmalı değil bu konumda olabilirdi ve bu nedenle büyük olasılıkla doğru tedavi olmaz şeyi beklenen. Mümkün olduğu kadar spesifik olun, böylece yalnızca olacağını bildiğinizleri yakalayın ve yukarıda belirtilen gürültülü ölüme kadar kabarcıktan önce görülmeyenleri yakalayın .

Kötü değil, sadece belirli avların daha iyi olması. Spesifik olduğunuzda, uygulamanızın ne yaptığını daha somut olarak anladığınız ve bunun üzerinde daha fazla kontrol sahibi olduğunuz anlamına gelir. Genel olarak, sadece bir İstisna'yı yakaladığınız, kayıt ettiğiniz ve devam ettiğiniz bir durumla karşılaşırsanız, muhtemelen bazı kötü şeyler oluyor. Bir kod bloğu veya yöntemin fırlayabileceğini bildiğiniz istisnaları özel olarak yakalarsanız, yalnızca günlük kaydı yapmak ve en iyisini ummak yerine , aslında kurtarabilirsiniz .

İki olasılık birbirini dışlayan değil.

İdeal bir durumda, yönteminizin üretebileceği tüm olası istisna türlerini yakalar, istisna başına ele alır ve sonunda catchgelecek veya bilinmeyen istisnaları yakalamak için genel bir madde eklersiniz . Bu şekilde her iki dünyanın da en iyisini elde edersiniz.

try
{
    this.Foo();
}
catch (BarException ex)
{
    Console.WriteLine("Foo has barred!");
}
catch (BazException ex)
{
    Console.WriteLine("Foo has bazzed!");
}
catch (Exception ex)
{
    Console.WriteLine("Unknown exception on Foo!");
    throw;
}

Daha özel istisnaları yakalamak için önce bunları koymalısınız.

Düzenleme: Yorumlarda belirtilen nedenlerden dolayı, son yakalamada bir yeniden inceleme eklendi.

Son zamanlarda aynı konuda duruyorum ve geçici sonucum, .NET İstisnası hiyerarşisinin ciddi şekilde berbat olduğu için tek sorunun ortaya çıktığı .

Örneğin, asılıyor atın olabilir bir istisna için makul bir aday yok çünkü, yakalamak istiyorum eğilimindedir kod ziyade meşru bir çalışma zamanı hatası bir hata gösterir. Ah evet. Öyleyse, bunun doğrudan bir sonucu olması dışında, tüm "mantıksal hataları" yakalamak için (veya yakalamamak) içine koyabileceğiniz hiçbir kova yoktur.ArgumentNullExceptionNullReferenceExceptionNullReferenceExceptionSystemException

Sonra IMNSHO orada büyük olmasının becerememek SEHException(via derived ExternalException) SystemExceptionve böylece "normal" haleSystemException Bir aldığınızdaSEHException, bir dökümü yazmak ve mümkün olduğunca hızlı sonlandırmak istiyorum - .NET 4 ile başlayan ve en azından bazı SEH istisnaları,yakalanmayacak Yolsuzluk Devlet İstisnaları olarak kabul edilir. İyi bir şey veCA1031kuralı daha da işe yaramazhale getiren bir gerçek, çünkü artık tembelinizcatch (Exception)bu en kötü türleri yakalayamayacak.

Ardından, diğer Çerçeve şeyler oldukça tutarsız ya türetir görünüyor Exceptiondoğrudan veya üzeri SystemExceptionşiddeti moot gibi bir şey tarafından yakalama maddeleri gruplama herhangi bir girişimi yapım.

Sayın Lippert tarafından parçası var C#şöhret denen Vexing İstisna o istisnaların bazı yararlı kategorizasyonlarını bırakır: Sen ... hariç, sadece "eksojen" olanları yakalamak istiyor iddia edilebilir C#dil ve .NET tasarım çerçeve istisnaları, herhangi bir şekilde “sadece dışsal olanları” yakalamayı imkansız kılar. _{(ve, örneğin, bir OutOfMemoryExceptionolabilir çok iyi bir şekilde büyük tamponlar ayrılmaz gereken bir API için tamamen normal bir kurtarılabilir hata olabilir)}

Benim için Alt satırda yani, yolu C#catch blokları çalışmak ve Çerçeve istisna hiyerarşi tasarlanmıştır yolu, kural CA1031tamamen yararsız ötesinde . O süsü "istisnalar yutmayn" ama istisnalar yutma ama ne, sen yakalamak ne ilgisi sıfır sahip kök sorunun giderilebilmesi için daha sonra yapın:

Orada en az 4 yolu meşru bir yakalandı işlemek için Exceptionve CA1031sadece yüzeysel bir tanesini (yani yeniden atış harf) işlemek gibi görünüyor.

Bir yandan not olarak, o zamandan beri biraz daha geçerli olacak Özel Durum Filtreleri adında bir C # 6 özelliği CA1031vardır; bu nedenle, yakalamak istediğiniz istisnaları gerektiği gibi düzgün bir şekilde filtreleyebilecek ve filtrelenmemiş bir yazı yazmak için daha az neden olacaktır catch (Exception).

Pokemon istisnası işleme (hepsini yakalaman lazım!) Kesinlikle her zaman kötü değildir. Bir yöntemi bir müşteriye gösterdiğinizde, özellikle son kullanıcı, uygulamanızın çökmesi ve yanması yerine her şeyi ve her şeyi yakalamak genellikle daha iyidir.

Genel olarak, olabildiğince kaçınılması gerektiği halde. İstisna türünü temel alarak belirli bir eylemde bulunmazsanız, istisnasız hareket etmemesi ve istisnanın kabarmasına izin vermek yerine istisnayı yutmak veya yanlış şekilde ele almak mümkündür.

Daha fazla okuma için bu SO cevabına bir göz atın .

Genel istisna yakalamak kötü bir programdır çünkü programınızı tanımsız bir durumda bırakır. Nerede yanlış gittiğini bilmiyorsunuz, böylece programınızın gerçekte ne yaptığını ya da yapmadığını bilmiyorsunuz.

Bir programı kapatırken, hepsini yakalamaya izin vereceğim yer. Tamamen temizleyebildiğin sürece. Kapattığınız bir program kadar sinir bozucu olan hiçbir şey yoktur; sadece orada oturmaktan başka bir şey yapmaz, uzağa gitmez ve bilgisayarınızın kapanmasını önler.

Dağıtılmış bir ortamda log yönteminiz geri tepebilir: genel bir istisna yakalamak, programınızın hala diğer kullanıcıların günlük kaydı yapmasını engelleyen bir günlük dosyası üzerinde kilitlenebileceği anlamına gelebilir.

Bu kuralın gerekçesini anlıyorum. Ancak uygulamada, atılan istisnadan bağımsız olarak aynı işlemi yapmak istersem, neden her birini özel olarak ele alacağım?

Diğerlerinin de söylediği gibi, atılan istisnadan bağımsız olarak, yapmak isteyeceğiniz bir işlemi hayal etmek (imkansız değilse de) gerçekten zor. Yalnızca bir örnek, programın durumunun bozulduğu ve herhangi bir başka işlemin sorunlara yol açabileceği durumlardır (bu, gerekçeli gerekçedir Environment.FailFast).

Ayrıca, belirli istisnaları ele alırsam, aradığım kod gelecekte yeni bir istisna oluşturmak üzere değişirse ne olur? Şimdi bu yeni istisnayı ele almak için kodumu değiştirmem gerekiyor. Oysa eğer İstisna'yı basitçe yakaladıysam kodumun değişmesi gerekmiyor.

Hobi kodu için yakalamak yeterlidir Exception, ancak profesyonel sınıf kod için yeni bir istisna türü tanıtan yöntem imzasındaki bir değişiklikle aynı şekilde ele alınmalıdır, örn. Kırılma değişikliği olarak kabul edilmelidir. Bu bakış açısına abone olduysanız, hemen değişiklik yapmanın (veya doğrulamanın) müşteri kodunun tek doğru eylem şekli olduğu hemen bellidir.

Örneğin, Foo Bar'ı çağırırsa ve Foo'nun Bar tarafından atılan istisna türünden bağımsız olarak işlemeyi durdurması gerekiyorsa, yakaladığım istisna türüne özgü olmanın herhangi bir avantajı var mı?

Elbette, çünkü sadece atılan istisnaları yakalayamayacaksınız Bar. Ayrıca Bar'ın istemcilerinin hatta çalışma zamanının Barçağrı yığındaki süre boyunca atabileceği istisnalar da olacaktır . İyi yazılmışlar, Bargerektiğinde kendi istisna türlerini tanımlamalı ve böylece arayanlar kendileri tarafından yayımlanan istisnaları özel olarak yakalayabilsinler.

Peki ya OutOfMemoryException dışındaki her istisnayı yoksaymak istersem?

IMHO, istisnaların ele alınması hakkında düşünmenin yanlış yoludur. Kara listelerde değil, beyaz listelerde (A ve B istisna tiplerini yakalayın) çalışmalısınız (X dışındaki tüm istisnaları yakalayın).

Belki . Her kuralın istisnaları vardır ve hiçbir kural eleştirel olarak izlenmemelidir. Örneğin , tüm istisnaları yutmanın mantıklı olduğu örneklerden biri olabilirsiniz . Örneğin, kritik bir üretim sistemine izleme eklemek istiyorsanız ve değişikliklerin uygulamanızın ana görevini bozmadığından kesinlikle emin olmak istiyorsanız.

Ancak , hepsini sessizce görmezden gelmeye karar vermeden önce başarısızlığın olası nedenlerini dikkatlice düşünmelisiniz. Örneğin, istisnanın nedeni şuysa:

• Günlük tutma yönteminde her zaman belirli bir istisna atmasına neden olan bir programlama hatası
• yapılandırma dosyasındaki günlük dosyasına giden geçersiz bir yol
• disk dolu

Derhal bu sorunun mevcut olduğu hakkında bilgilendirilmek istemezseniz, düzeltebilirsiniz. İstisnayı yutmak, hiçbir şeyin yanlış gittiğini asla bilemeyeceğiniz anlamına gelir.

Bazı sorunlar (disk dolu gibi) uygulamanın diğer bölümlerinin de başarısız olmasına neden olabilir - ancak bu hata şimdi kaydedilmedi, bu yüzden asla bilemeyeceksiniz!

Bunu teknik olarak değil, mantıklı bir bakış açısıyla ele almak istiyorum.

Şimdi bu yeni istisnayı ele almak için kodumu değiştirmem gerekiyor.

Eh, biri başa çıkmak zorunda kalacak. Fikir bu. Kütüphane kodu yazarları, yeni istisna türleri eklemek konusunda ihtiyatlı olacaktır, ancak müşterileri kırması muhtemeldir, bununla çok sık karşılaşmamalısınız.

Sorunuz temelde "Neyin yanlış gittiğini umursamıyorsam? Gerçekten ne olduğunu bulma zorluğundan geçmek zorunda mıyım?"

İşte güzellik kısmı: hayır yok.

“Öyleyse, diğer tarafa bakabilir ve ne kötü bir şey çıkarsa, halının altına otomatik olarak süpürülüp bununla bitebilir miyim?”

Hayır, bu da işe yaramadı.

Mesele şu ki, olası istisnaların toplanması, her zaman beklediğiniz koleksiyondan daha büyüktür ve yerel küçük probleminiz bağlamında ilgilenir. Beklediklerinizle ilgileniyorsunuz ve beklenmeyen bir şey olursa, yutmak yerine daha üst düzey işleyicilere bırakıyorsunuz. Beklemeyeceğiniz bir istisnayı umursamıyorsanız, çağrı yığınında bulunan birisinin iddiaya gireceğini ve işleyicisine ulaşmadan önce bir istisnayı öldürmek için sabotaj olacaktır.

“Ama… ama… o zaman umursamadığım diğer istisnalardan biri görevimin başarısız olmasına neden olabilir!”

Evet. Ancak yerel olarak ele alınanlardan sonra her zaman daha önemli olacaklar. Bir yangın alarmı ya da patronun ne yaptığınızı durdurmanızı ve ortaya çıkan daha acil bir görevi almanızı söyleyen gibi.

Genel istisnaları her işlemin en üst düzeyinde yakalamanız ve hatayı olabildiğince bildirerek ve işlemi sonlandırarak halletmeniz gerekir.

Genel istisnalar yakalamamalı ve uygulamaya devam etmeye çalışmalısınız.