Mantıksal operatörler olarak Try / Catch'i kullanmaya karşı veya bununla ilgili argümanlar [kapalı]

Şirketlerimizde Try-Catch bloklarını mantıksal operatörler olarak kullanan bazı hoş kodları keşfettim.
Anlamı, "bir kod uygulayın, eğer bu hatayı atarsa, bu kodu yapın, ancak bu hatayı atarsa, bunun yerine bu 3. şeyi yapın".
Göründüğü gibi "else" ifadesini "Son" olarak kullanır.
Bunun doğal olarak yanlış olduğunu biliyorum, ancak kavga almaya başlamadan önce bazı iyi düşünülmüş argümanları umuyordum.
Ve hey, bu şekilde Try-Catch kullanımı için argümanlarınız varsa, lütfen söyleyin.

Merak edenler için, dil C # ve söz konusu kod yaklaşık 30+ satır ve belirli istisnalar arıyor, TÜM istisnaları ele almıyor.

İstisna işleme, akış kontrolünü ele almanın pahalı bir yolu olma eğilimindedir (kesinlikle C # ve Java için).

Bir istisna nesnesi oluşturulduğunda çalışma zamanı oldukça fazla iş yapar - istifin bir araya getirilmesi, istisnanın nerede işlendiğini bulmak ve daha fazlası.

Akış kontrolü için akış kontrolü ifadeleri kullanılıyorsa, bellek ve CPU kaynaklarındaki tüm bu maliyetlerin genişletilmesi gerekmez.

Ayrıca, anlamsal bir sorun var. İstisnalar, normal akış kontrolü için değil istisnai durumlar içindir. Biri, normal program akışı olarak değil, beklenmeyen / istisnai durumları ele almak için istisna işlemeyi kullanmalıdır, çünkü aksi takdirde yakalanmamış bir istisna size çok daha az şey söyleyecektir.

Bu ikisinin dışında, kodu okuyan başkalarının meselesi var. İstisnaları bu şekilde kullanmak çoğu programcının beklediği bir şey değildir, bu yüzden okunabilirlik ve kodunuzun ne kadar anlaşılır olduğunu. Biri "İstisna" yı gördüğünde, birileri kötü bir şey oldu, normalde olması gerekmeyen bir şey olduğunu düşünüyor. Dolayısıyla, istisnaları bu şekilde kullanmak sadece kafa karıştırıcıdır.

Şirketlerimizde Try-Catch bloklarını mantıksal operatörler olarak kullanan bazı hoş kodları keşfettim. Anlamı, "bir kod uygulayın, eğer bu hatayı atarsa, bu kodu yapın, ancak bu hatayı atarsa, bunun yerine bu 3. şeyi yapın". Göründüğü gibi "else" ifadesini "Son" olarak kullanır. Bunun doğal olarak yanlış olduğunu biliyorum.

Bunu nasıl biliyorsun? Tüm bu tür "bilgiyi" bıraktım ve şimdi en basit kodun en iyisi olduğuna inanıyorum. Bir dize, ayrıştırma başarısız olursa boş olan bir isteğe bağlı olarak dönüştürmek istediğinizi varsayalım. Yanlış bir şey yok:

try { 
    return Optional.of(Long.valueOf(s)); 
} catch (NumberFormatException) { 
    return Optional.empty(); 
}

"İstisnalar istisnai durumlar içindir" ın genel yorumuna tamamen katılmıyorum. Bir işlev kullanılabilir bir değer döndüremezse veya bir yöntem kendi koşullarını yerine getiremiyorsa, bir istisna atayın. Gösterilen bir performans sorunu ortaya çıkana kadar bu istisnaların ne sıklıkta atıldığı önemli değildir.

Özel durumlar, hata işlemenin normal akıştan ayrılmasını sağlayarak kodu basitleştirir. Sadece mümkün olan en basit kodu yazın ve try-catch kullanmak veya bir istisna atmak daha kolaysa, bunu yapın.

İstisnalar, koddaki yol sayısını azaltarak testi kolaylaştırır. Dalları olmayan bir işlev ya tamam ya da bir istisna atar. ifHata kodlarını kontrol etmek için birden fazla ifadeye sahip bir fonksiyonun birçok olası yolu vardır. Koşullardan birini yanlış anlamak ya da tamamen unutmak çok kolaydır, böylece bazı hata durumları göz ardı edilir.

İstisnalar kullanılarak kontrol akışı yapıldığında hata ayıklama ve bakım işi çok zordur.

Doğal olarak, istisnalar, programınızın normal kontrol akışını değiştirme - olağandışı faaliyetler gerçekleştirme, alışılmadık yan etkilere neden olma, daha az karmaşık bir şekilde ele alınamayan özellikle sıkı bir bağlamadan kurtulmanın bir yolu olarak tasarlanmıştır. anlamına geliyor. İstisnalar olağanüstü. Bu, üzerinde çalıştığınız belirli bir ortama bağlı olarak, düzenli kontrol akışı için istisna kullanımının neden olabileceği anlamına gelir:

• Verimlilik İstisnalar için gerekli göreceli olarak zor bağlam değişikliklerini güvenli bir şekilde gerçekleştirmek için çevrenin atlaması gereken ek halkalar enstrümantasyon ve kaynaklar gerektirir.

• Hata ayıklama zorlukları Bazen yararlı (bir programın hatalarını ayıklamaya çalışırken) bilgiler istisnalar ortaya çıktığında pencereden atılır. Çalışma zamanı davranışını anlamak için ilgili program durumunu veya geçmişini kaybedebilirsiniz

• Bakım sorunları Uygulama akışını istisna atlamalarla izlemek zor. Bunun ötesinde, bir istisna atarken, anlaşılması kolay olmayan davranışlarda bulunabilen kara kutu tipi kodunun içinden bir istisna atılabilir.

• Zayıf tasarım kararları Bu şekilde inşa edilen programlar, çoğu durumda, problemleri zarif bir şekilde çözmek için kolayca eşleşmeyen bir zihin çerçevesini teşvik eder. Nihai programın karmaşıklığı, programcının yürütmesini tam anlamıyla yerine getirmesini engeller ve yüksek uzun vadeli maliyetlerle kısa vadeli iyileştirmelere yol açan kararları almaya teşvik eder.

Bu deseni birkaç kez kullandım.

2 büyük sorun var:

• Son derece pahalıdır (istisna nesnesinin somutlaştırılması, çağrı yığınının toplanması vb.). Bazı derleyiciler onu gerçekten optimize edebiliyor olabilirler, ancak istisnalar böyle bir kullanım için tasarlanmadığından bu durumda buna güvenmezdim, bu yüzden insanların bunun için optimize etmesini bekleyemezsiniz.
• Kontrol akışı için istisnalar kullanmak aslında a'ya benzer bir sıçramadır goto. Atlayışlar, birçok nedenden dolayı zararlı olarak kabul edilir. Tüm alternatiflerin önemli dezavantajları varsa, kullanılmaları gerekir. Aslında, tüm kodlarımı atlar açıkça en iyi çözüm olduğu sadece 2 vakaları hatırlıyorum.

Bazen istisnalar en hızlısıdır. Boş nesne istisnalarının Java'da bile kontrol yapılarını kullanmaktan daha hızlı olduğu durumlar gördüm (şu anda çalışmayı alıntılayamam, bu yüzden bana güvenmek zorunda kalacaksınız). Sorun, Java'nın zaman ayırması ve yerel olanları (en azından kısmen önbelleğe alınmış gibi görünüyor) kullanmak yerine, bir özel istisna sınıfının yığın izini doldurması gerektiğinde ortaya çıkar. Bir şeyin tek taraflı olarak daha hızlı veya daha yavaş olduğunu söylemeden önce kıyaslama yapmak iyi olur.

Python'da sadece daha hızlı olmakla kalmıyor, aynı zamanda istisnaya neden olabilecek bir şey yapmak ve hatayı düzeltmek de çok daha doğru. Evet, bir tür sistemi uygulayabilirsiniz, ancak bu dil felsefesine aykırıdır - bunun yerine yöntemi çağırmaya ve sonucu yakalamaya çalışmalısınız! (Bir dosyanın yazılabilir olup olmadığını test etmek benzerdir - sadece yazmayı deneyin ve hatayı yakalayın).

PHP + MySQL'de bir tablonun bulunup bulunmadığını anlamaktan başka olmayan sorgu tabloları gibi aptalca bir şey yapmanın daha hızlı olduğu zamanları gördüm ( bu konuyu karşılaştırdığım soru aslında benim olumsuz oylarla kabul edilen tek cevabım) .

Bunların hepsi, istisnaların kullanımı çeşitli nedenlerle sınırlandırılmalıdır:

1. İç içe istisnaların yanlışlıkla yutulması. Bu büyük. Başkasının üstesinden gelmeye çalıştığı derinlemesine iç içe geçmiş bir istisna yakalarsanız, sadece diğer programcınızı (belki siz bile!) Ayağınızdan vurdunuz.
2. Testler belirginleşmiyor. İçinde istisna olan bir kod bloğu, içinde yanlış olan birkaç şeyden birine sahip olabilir. Öte yandan, bir boolean teorik olarak hata ayıklamak için can sıkıcı olabilirken, genellikle değildir. Bu özellikle try...catchkontrol akışına bağlı tutulanların (benim deneyimlerime göre) felsefesini "deneme bloğunda minimize et" felsefesini takip etmediği için geçerlidir.
3. Bir else ifblok için izin vermiyor . Yeterli dedi (ve eğer biri "Ama farklı istisnalar sınıfları kullanabilirlerdi").
4. Dilbilgisi yanıltıcıdır. Exception, dünyanın geri kalanına ( try...catchkontrol akışı felsefesine bağlı olmadığı gibi ), bir şeyin dengesiz (belki de kurtarılabilir) bir duruma girdiği anlamına gelir. Kararsız durumlar kötüdür ve aslında kaçınılabilir istisnalar varsa (aslında beni korkutur, yalanlar yok), geceleri hepimizi ayakta tutmalı.
5. Ortak kodlama stili ile uyumlu değildir. Yaptığımız iş hem kodumuz hem de kullanıcı arayüzümüz ile dünyayı mümkün olduğunca açık hale getirmektir. try...catchkontrol akışı genellikle en iyi uygulamalar olarak kabul edilenlere karşı gider. Bu, bir projede yeni birisinin projeyi öğrenmesi için daha fazla zaman aldığı anlamına gelir; bu da kesinlikle kazanılmaması için çalışma saatlerinde bir artış anlamına gelir.
6. Bu genellikle kod çoğaltmaya yol açar. Son olarak, bloklar, kesinlikle gerekli olmasa da, kesilen deneme bloğu tarafından açık bırakılan tüm sarkan işaretçileri çözme ihtiyacı duyar. Öyleyse blokları dene. Bu, sahip olabileceğiniz anlamına gelir try{ obj.openSomething(); /*something which causes exception*/ obj.doStuff(); obj.closeSomething();}catch(Exception e){obj.closeSomething();}. Daha geleneksel bir if...elsesenaryoda, closeSomething()kopyalayıp yapıştırma işi olma olasılığı (yine kişisel deneyim) daha düşüktür. (Kuşkusuz, bu belirli argümanın gerçek felsefenin kendisinden daha çok tanıştığım insanlarla ilgisi var).

Benim ana argümanım mantık için try / catch kullanmak mantıksal akışı keser. Mantık dışı yapılar yoluyla "mantık" takiben (bana) karşı sezgisel ve kafa karıştırıcı. Mantığımı "Durum sonra A başka bir B" olarak okumak için alışkınım. "Try A catch sonra B'yi uygulayın" ile aynı ifadeyi okumak garip geliyor. İfadenin Abasit bir atama olup olmadığı conditiondaha da ifgariptir , yanlışsa bir istisna zorlamak için fazladan kod gerektirir (ve bunu yapmak muhtemelen yine de bir açıklama gerektirir ).

Eh, sadece görgü kuralları meselesi, "onlarla tartışmaya başlamadan" önce, belirttiğiniz gibi, "Neden tüm bu farklı yerlerde istisna işleme kullanıyorlar?"

Yani, birkaç olasılık var:

1. beceriksizler
2. ilk bakışta görünmeyen, yaptıkları için kusursuz bir sebep var.
3. bazen bir zevk meselesidir ve bazı karmaşık program akışını basitleştirebilir.
4. Henüz kimsenin değişmediği ve biri yaparsa mutlu olacakları geçmişin bir kalıntısı.

... bunların hepsinin eşit derecede muhtemel olduğunu düşünüyorum. Öyleyse onlara güzelce sorun.

Catch'i deneyin, sadece istisnaların ele alınması için kullanılmalıdır. Daha çok, belirli özel durum işleme. Deneme yakalamanız yalnızca beklenen istisnaları yakalamalıdır, aksi halde iyi oluşturulmamış olması gerekir. Eğer bir yakalama kullanmaya ihtiyacınız varsa, hepsini yakalamaya çalışın, o zaman muhtemelen yanlış bir şey yapıyorsunuzdur.

DÜZENLE:

Sebep: Koşullu operatör olarak try catch kullanıyorsanız, REAL istisnalarını nasıl hesaba katacağınızı savunabilirsiniz.

İstisna, İstisnai şey olduğu zaman içindir. Program normal iş akışına göre çalışıyor mu?

İstisnaları kullanma nedeni:

1. İstisnai bir durumu yakalamayı unutursanız, programınız ölecek ve yığın izi size tam olarak nedenini söyleyecektir. Bir istisna durumu için dönüş değerini ele almayı unutursanız, programınızın ne kadar uzakta yanlış davranış sergileyeceği söylenemez.
2. Dönüş değerlerinin kullanılması yalnızca dönebileceğiniz bir sentinel değeri varsa çalışır. Mümkün olan tüm dönüş değerleri zaten geçerliyse, ne yapacaksınız?
3. Bir istisna, ne olabileceği konusunda faydalı olabilecek ek bilgiler taşıyacaktır.

İstisnaları kullanmama nedenleri:

1. Çoğu dil, istisnaları hızlı hale getirmek için tasarlanmamıştır.
2. Yığını birkaç kat yukarı hareket ettiren istisnalar, uyanıklıklarını uyanıklık halinde bırakabilir.

Sonunda:

Amaç, neler olduğunu bildiren bir kod yazmaktır. İstisnalar, kodun ne yaptığına bağlı olarak yardımcı olabilir / engelleyebilir. Bir sözlük referansındaki bir KeyError için python'da denemek / yakalamak mükemmeldir (dili bildiğiniz sürece), aynı KeyError beş işlev katmanının uzağındaki aynı KeyError'ı denemek / yakalamak tehlikelidir.

Bazı durumlarda try-> catch'i akış kontrolü olarak kullanırım. Birincil mantığınız başarısız olan bir şeye bağlıysa, ancak bir istisna atmak ve istifa etmek istemezseniz ... Bu bir try-> catch bloğu içindir. Çok fazla izlemesiz sunucu tarafı unix komut dosyası yazıyorum ve onların başarısız olmamaları için, çok daha önemli olmaları çok daha önemli.

Yani deneyin Planı A ve A Planı ölür, eğer av ve Plan B ile çalışacak ... Ve B planı, kullanımı başarısız olursa nihayet Planı C kapalı tekme için, hangi edecek A veya B veya sayfanın başarısız hizmetlerden birini düzeltme biri ben mi.

Dile ve belki de kullanılan uygulamaya bağlıdır. C ++ 'daki standart, istisnaların gerçekten istisnai olaylar için kaydedilmesi gerektiğidir. Öte yandan, Python'da kılavuzlardan biri “ izin almaktan daha af istemek daha kolay ” dır , bu nedenle deneme mantığı dışında try / exc bloklarının entegrasyonu teşvik edilir.

Bu kötü bir alışkanlık ama bunu bazen python ile yapıyorum. Bir dosyanın olup olmadığını kontrol etmek yerine, sadece onu silmeyi denerim. Bir istisna atarsa, orada olmadığını bilmeye devam ederim. <== (başka bir kullanıcı dosyaya sahipse mutlaka doğru değildir, ancak bunu bir kullanıcının ana dizininde yapıyorum, bu yüzden bu SHOULDN'T olur).

Yine de, aşırı kullanılmış bu kötü bir uygulama.

Apple'ın tanımladığı şekli seviyorum : İstisnalar yalnızca programcı hataları ve ölümcül çalışma zamanı hataları içindir. Başka kullanım hata kodları. Ne zaman kullanılacağına karar vermeme yardımcı oluyor ve kendi kendime "Bu programcı bir hata mıydı?" Diye düşünüyor.

Bu, bir goto komutu olmayan bir dilin üstüne bir goto mantığı oluşturmak için istisna işleme kullanmak gibi görünüyor.

Goto mantığının kötü olmasının birçok nedeni için bu soruya başvurabilirsiniz: https://stackoverflow.com/questions/46586/goto-still-considered-harmful