Neden her bloğu “dene” - “yakala”?

Her zaman, bir yöntem bir istisna atabilirse, bu çağrıyı anlamlı bir deneme bloğu ile korumamanın pervasız olduğuna inanıyorum.

Ben sadece ' HER ZAMAN denemek, blokları yakalamak çağrıları sarmak gerekir yayınladı . ' bu soruya ve' oldukça kötü bir tavsiye 'olduğu söylendi - nedenini anlamak istiyorum.

Bir yöntem yalnızca mantıklı bir şekilde işleyebiliyorsa bir istisna yakalamalıdır.

Aksi takdirde, çağrı yığınının yukarısındaki bir yöntemin mantıklı olabileceği umuduyla, üst üste aktarın.

Diğerlerinin belirttiği gibi, ölümcül hataların günlüğe kaydedilmesini sağlamak için çağrı yığınının en üst düzeyinde işlenmeyen bir istisna işleyicisine (günlük kaydıyla) sahip olmak iyi bir uygulamadır.

As Mitch ve diğerleri belirtildiği, size bir şekilde ele planı yok o bir istisna yakalamak gerekir. Uygulamayı tasarlarken istisnaları sistematik olarak nasıl ele alacağını düşünmelisiniz. Bu genellikle soyutlamalara dayalı hata işleme katmanlarına sahip olur - örneğin, veri erişim kodunuzdaki SQL ile ilgili tüm hataları işlersiniz, böylece uygulamanın etki alanı nesneleriyle etkileşim kuran kısmı, başlık altında bir yerde bir DB.

Kesinlikle "her yerde yakalamak" kokusuna ek olarak kesinlikle kaçınmak istediğiniz birkaç ilgili kod kokuları vardır .

1. "catch, log, rethrow" : Kapsamlı günlük kaydı istiyorsanız, bir istisna (ala std::uncaught_exception()) nedeniyle yığın açılırken yıkıcısına bir günlük deyimi yayan bir sınıf yazın . Yapmanız gereken tek şey, ilgilendiğiniz kapsamda bir günlük kaydı örneği bildirmektir ve işte, günlük kaydı vardır ve gereksiz try/ catchmantık yoktur .

2. "yakalamak, tercüme etmek atmak" : bu genellikle bir soyutlama sorununa işaret eder. Birkaç özel istisnayı daha genel bir çözüme dönüştürdüğünüz birleşik bir çözüm uygulamadığınız sürece, muhtemelen gereksiz bir soyutlama katmanınız vardır ... ve "yarın buna ihtiyacım olabilir" demeyin .

3. "yakala, temizle, tekrar et" : bu benim evcil hayvanımdan biri. Bunların çoğunu görürseniz, Kaynak Edinme Başlatma tekniklerini uygulamalı ve temizleme bölümünü bir hademe nesnesi örneğinin yıkıcısına yerleştirmelisiniz .

Ben kod inceleme ve yeniden düzenleme için iyi bir hedef olarak try/ catchblokları ile çevrili kodu düşünün . İstisna işlemenin iyi anlaşılmadığını veya kodun bir amœba haline geldiğini ve ciddi bir yeniden düzenleme ihtiyacı olduğunu gösterir.

Bir sonraki soru "Bir istisna yakaladım, sonra ne yapacağım?" Ne yapacaksın? Hiçbir şey yapmazsanız - bu hata gizleme ve program ne olduğunu bulma şansı olmadan "sadece işe yaramadı". İstisnayı yakaladıktan sonra tam olarak ne yapacağınızı anlamanız ve sadece biliyorsanız yakalamanız gerekir.

Sen kapsayacak gerekmez her bir try-catch hala çağrı yığını altındaki fonksiyonlarda atılan işlenmemiş özel durumlar yakalamak çünkü deneme-yakalar bloğu. Bu nedenle, her işlevin bir deneme yakalaması yerine, uygulamanızın en üst düzey mantığına sahip olabilirsiniz. Örneğin, SaveDocument()diğer yöntemleri vb. Çağıran birçok yöntemi çağıran bir üst düzey rutin olabilir . Bu alt yöntemler kendi deneme yakalamalarına ihtiyaç duymaz, çünkü atarlarsa hala yakalama tarafından SaveDocument()yakalanırlar.

Bu üç nedenden dolayı güzel: bir hata bildirmek için tek bir yeriniz olduğu için kullanışlıdır: SaveDocument()catch blok (lar) ı. Bunu tüm alt yöntemler boyunca tekrarlamaya gerek yoktur ve yine de istediğiniz şeydir: kullanıcıya yanlış giden bir şey hakkında yararlı bir teşhis vermek için tek bir yer.

İkinci olarak, bir istisna atıldığında kaydetme iptal edilir. Her alt yöntem try-catch ile, bir istisna atılırsa, bu yöntemin catch bloğuna girersiniz, yürütme işlevi terk eder ve devam eder SaveDocument(). Eğer bir şeyler zaten yanlış giderse, muhtemelen orada durmak istersiniz.

Üç, tüm alt yöntemleriniz her çağrının başarılı olduğunu varsayabilir . Bir çağrı başarısız olursa, yürütme catch bloğuna atlar ve sonraki kod hiçbir zaman yürütülmez. Bu, kodunuzu daha temiz hale getirebilir. Örneğin, hata kodlarıyla birlikte:

int ret = SaveFirstSection();

if (ret == FAILED)
{
    /* some diagnostic */
    return;
}

ret = SaveSecondSection();

if (ret == FAILED)
{
    /* some diagnostic */
    return;
}

ret = SaveThirdSection();

if (ret == FAILED)
{
    /* some diagnostic */
    return;
}

Bunun istisnalar dışında nasıl yazılacağı aşağıda açıklanmıştır:

// these throw if failed, caught in SaveDocument's catch
SaveFirstSection();
SaveSecondSection();
SaveThirdSection();

Şimdi ne olduğu çok daha açık.

Özel durum güvenli kodunun başka yollarla yazılması daha zor olabilir: bir istisna atılırsa herhangi bir belleğe sızmak istemezsiniz. İstisnalardan önce nesneler her zaman tahrip edildiğinden, RAII , STL kapları, akıllı işaretçiler ve kaynaklarını yıkıcılarda serbest bırakan diğer nesneleri bildiğinizden emin olun .

Herb Sutter bu sorun hakkında burada yazdı . Herhalde okumaya değer.
Fragman:

"İstisna-güvenli kod yazmak temelde doğru yerlere" dene "ve" yakala "yazmakla ilgilidir." Tartışır.

Açıkçası, bu ifade istisna güvenliğinin temel bir yanlış anlaşılmasını yansıtır. İstisnalar sadece hata raporlamanın başka bir şeklidir ve kesinlikle hata korumalı kod yazmanın sadece dönüş kodlarını nereden kontrol edeceğiniz ve hata koşullarını nasıl ele alacağımızla ilgili olmadığını biliyoruz.

Aslında, istisna güvenliğinin nadiren 'denemek' ve 'yakalamak' yazmakla ilgili olduğu ortaya çıkıyor - ve daha nadiren daha iyi. Ayrıca, istisna güvenliğinin bir kod tasarımını etkilediğini asla unutmayın; Baharat için olduğu gibi birkaç ekstra yakalama ifadesi ile uyarlanabilecek sadece bir sonradan düşünülemez.

Diğer yanıtlarda belirtildiği gibi, yalnızca bir tür mantıklı hata işleme yapabiliyorsanız bir istisna yakalamanız gerekir.

Örneğin , sorunuzu ortaya çıkaran soruda, soru soran lexical_cast, bir tamsayıdan dizgeye kadar olan istisnaları göz ardı etmenin güvenli olup olmadığını sorar . Böyle bir oyuncu asla başarısız olmamalı. Başarısız olursa, programda bir şeyler çok yanlış gitti. Bu durumda iyileşmek için ne yapabilirsiniz? Muhtemelen programın ölmesine izin vermek en iyisidir, çünkü güvenilir olmayan bir durumdadır. Bu nedenle, istisnayı ele almamak en güvenli şey olabilir.

İstisnaları her zaman istisna atabilecek bir yöntemin arayanında hemen ele alırsanız, istisnalar işe yaramaz hale gelir ve hata kodlarını kullanmanız daha iyi olur.

İstisnaların asıl amacı, çağrı zincirindeki her yöntemde ele alınmaları gerekmemesidir.

Duyduğum en iyi tavsiye, istisnai durum hakkında makul bir şey yapabileceğiniz noktalarda istisnaları yakalamanız gerektiğidir ve "yakala, kaydet ve bırak" iyi bir strateji değildir (bazen kütüphanelerde kaçınılmazsa).

Mümkün olan en düşük düzeyde istisnaları ele almak için sorunuzun temel yönüne katılıyorum.

Mevcut cevaplardan bazıları "İstisna ile başa çıkmanıza gerek yok. Başka biri bunu yığınının üstünde yapacak." Deneyimlerime göre, şu anda geliştirilen kod parçasında istisna işleme hakkında düşünmemek , bir başkasının veya daha sonra problemi istisna haline getirmek için kötü bir bahane .

Bu sorun, bir iş arkadaşı tarafından uygulanan bir yöntemi çağırmanız gerekebilecek dağıtılmış geliştirmede önemli ölçüde büyüyor. Ve sonra size neden bazı istisnalar attığını öğrenmek için iç içe bir yöntem çağrıları zincirini incelemeniz gerekir; bu, en derin iç içe yöntemde çok daha kolay ele alınabilirdi.

Bilgisayar bilimi profesörümün bana bir kez verdiği öneri şuydu: "Try ve Catch bloklarını sadece hatayı standart yöntemlerle ele almak mümkün olmadığında kullanın."

Örnek olarak, bir programın, aşağıdaki gibi bir şey yapmanın mümkün olmadığı bir yerde ciddi bir sorunla karşılaşması durumunda şunları söyledi:

int f()
{
    // Do stuff

    if (condition == false)
        return -1;
    return 0;
}

int condition = f();

if (f != 0)
{
    // handle error
}

O zaman deneyin, blokları yakalamak gerekir. Bunun üstesinden gelmek için istisnalar kullanabilirsiniz, ancak istisnalar pahalı performans açısından akıllıca olduğu için genellikle önerilmez.

Her işlevin sonucunu test etmek istiyorsanız, dönüş kodlarını kullanın.

İstisnaların amacı, sonuçları daha az test edebilmenizdir. Fikir, istisnai (olağandışı, daha nadir) koşulları daha sıradan kodunuzdan ayırmaktır. Bu, sıradan kodu daha temiz ve basit tutar - ancak yine de bu istisnai durumlarla başa çıkabilir.

İyi tasarlanmış kodda daha derin fonksiyonlar fırlayabilir ve daha yüksek fonksiyonlar yakalanabilir. Ancak kilit nokta, "aradaki" birçok işlevin istisnai koşulların üstesinden gelme yükünden muaf olacağıdır. Sadece "istisna güvenli" olmaları gerekir, bu da yakalamaları gerektiği anlamına gelmez.

Bu tartışmaya, C ++ 11'den beri , her catchbloğun rethrowişlenebileceği / ele alınması gereken noktaya kadar istisna olduğu sürece çok mantıklı olduğunu eklemek isterim . Bu şekilde bir geri izleme oluşturulabilir . Bu nedenle önceki görüşlerin kısmen modası geçmiş olduğuna inanıyorum.

Kullan std::nested_exceptionvestd::throw_with_nested

Burada ve burada StackOverflow'da bunu nasıl başaracağınız anlatılmaktadır .

Bunu herhangi bir türetilmiş istisna sınıfıyla yapabileceğiniz için, böyle bir geri izlemeye çok fazla bilgi ekleyebilirsiniz! Ayrıca , bir backtrace'ın şöyle görüneceği GitHub'daki MWE'mize de göz atabilirsiniz :

Library API: Exception caught in function 'api_function'
Backtrace:
~/Git/mwe-cpp-exception/src/detail/Library.cpp:17 : library_function failed
~/Git/mwe-cpp-exception/src/detail/Library.cpp:13 : could not open file "nonexistent.txt"

Uygulamanın çok fazla hatası olduğu ve kullanıcıların sorunlardan ve çalışmalardan bıktıkları için birkaç projeyi kurtarmak için "fırsat" verildi ve yöneticiler tüm dev ekibinin yerini aldı. Bu kod tabanlarının tümü, en üst oyu verilen yanıtın açıkladığı gibi uygulama düzeyinde merkezi hata işlemeye sahipti. Bu cevap en iyi uygulamadırsa neden işe yaramadı ve önceki geliştirici ekibin sorunları çözmesine izin vermedi? Belki bazen işe yaramıyor? Yukarıdaki yanıtlar, geliştiricilerin tek sorunları düzeltmek için ne kadar zaman harcadıklarından bahsetmiyor. Sorunları çözmek için zaman anahtar metrikse, try..catch blokları ile enstrüman kodu daha iyi bir uygulamadır.

Ekibim kullanıcı arayüzünü önemli ölçüde değiştirmeden sorunları nasıl çözdü? Basit, her yöntem try..catch bloke edildi ve her şey, hata adı, hata mesajı, uygulama adı, tarih, ve sürüm. Bu bilgi ile geliştiriciler en çok oluşan istisnayı belirlemek için hatalar üzerinde analiz çalıştırabilir! Veya en fazla sayıda hata içeren ad alanı. Ayrıca, bir modülde oluşan bir hatanın düzgün bir şekilde işlendiğini ve birden fazla nedenden kaynaklanmadığını doğrulayabilir.

Bunun bir başka avantajı da geliştiricilerin hata günlüğü yönteminde bir kırılma noktası ayarlayabilmeleri ve bir kırılma noktası ve "adım atma" hata ayıklama düğmesine tek bir tıklama ile, gerçek tam erişim ile başarısız olan yöntemde hata noktasında, hemen pencerede bulunan nesneler. Hata ayıklamayı çok kolay hale getirir ve kesin satırı bulmak için sorunu çoğaltmak için yürütme yönteminin başlangıcına geri sürüklenmesine izin verir. Merkezi kural dışı durum işleme, bir geliştiricinin 30 saniye içinde bir kural dışı durumu kopyalamasına izin veriyor mu? Hayır.

"Bir yöntem yalnızca mantıklı bir şekilde işleyebiliyorsa bir istisna yakalamalıdır." Bu, geliştiricilerin yayınlanmadan önce meydana gelebilecek her hatayı tahmin edebileceklerini veya karşılaşacaklarını ima eder. Bu bir üst düzey doğru olsaydı, uygulama istisnası işleyicisine ihtiyaç duyulmazdı ve Elastik Arama ve logstash için pazar olmazdı.

Bu yaklaşım aynı zamanda geliştiricilerin üretimde aralıklı sorunları bulmasını ve düzeltmesini sağlar! Üretimde hata ayıklayıcı olmadan hata ayıklamak ister misiniz? Yoksa üzgün kullanıcılardan çağrı alıp e-posta almayı mı tercih edersiniz? Bu, başkalarını bilmeden ve sorunu çözmek için gereken her şey orada olduğu için destekle e-posta, IM veya Slack'e gerek kalmadan sorunları düzeltmenize olanak tanır. Sorunların% 95'inin çoğaltılması gerekmez.

Düzgün çalışması için, ad alanının / modülün, sınıf adının, yöntemin, girdilerin ve hata iletisinin yakalanabileceği ve hangi yöntemin en başarısız olduğunu vurgulamak üzere toplanabilmesi için bir veritabanında depolanabilen merkezi günlük kaydı ile birleştirilmesi gerekir. önce sabit.

Bazen geliştiriciler, yığını bir bloktan istisnalar atmayı seçer, ancak bu yaklaşım, atmayan normal koddan 100 kat daha yavaştır. Günlüğe kaydetme ile yakalama ve bırakma tercih edilir.

Bu teknik, 2 yılda 12 Devs tarafından geliştirilen bir Fortune 500 şirketinde çoğu kullanıcı için her saat başarısız olan bir uygulamayı hızlı bir şekilde stabilize etmek için kullanıldı. Bu 3000 kullanılarak 4 ay içinde farklı istisnalar tanımlanmış, sabitlenmiş, test edilmiş ve dağıtılmıştır. Bu, ortalama olarak 4 ay boyunca her 15 dakikada bir düzeltmeye çıkar.

Kod enstrümanı için gerekli olan her şeyi yazmanın eğlenceli olmadığını kabul ediyorum ve tekrarlayan koda bakmamayı tercih ediyorum, ancak her yönteme 4 satır kod eklemek uzun vadede buna değer.

Yukarıdaki tavsiyenin yanı sıra, şahsen bazı try + catch + throw kullanıyorum; aşağıdaki nedenle:

1. Farklı kodlayıcının sınırında, başkaları tarafından yazılan arayan için istisna yapılmadan önce, kendim tarafından yazılan kodda try + catch + throw kullanıyorum, bu bana kodumda meydana gelen bazı hata koşullarını öğrenme şansı veriyor ve Burası başlangıçta istisna atmak koduna çok daha yakın, daha yakın, nedeni bulmak daha kolay.
2. Modüllerin sınırında, aynı modülüm farklı modül yazılabilse de.
3. Öğrenme + Hata Ayıklama amacı, bu durumda C ++ 'da catch (...) ve C #' da catch (Exception ex) kullanıyorum, C ++ için standart kütüphane çok fazla istisna atmaz, bu nedenle bu durum C ++ 'da nadirdir. Ama C #, C # ortak bir yerde büyük bir kütüphane ve olgun bir istisna hiyerarşisi vardır, C # kütüphane kodu ton istisna atmak, teorik olarak ben (ve siz) aradığınız işlevden her istisna bilmeli ve nedenini / vakasını bilmelisiniz bu istisna atılır ve bunları nasıl ele alacağınızı bilir (yanından geçirin veya yerinde yakalayın ve ele alın). Ne yazık ki gerçekte, bir kod satırı yazmadan önce potansiyel istisnalar hakkında her şeyi bilmek çok zor. Bu yüzden hepsini yakalarım ve herhangi bir istisna gerçekten meydana geldiğinde (ürün ortamında) / onaylama iletişim kutusunu (geliştirme ortamında) kaydederek kodumun yüksek sesle konuşmasına izin verdim. Bu şekilde aşamalı olarak istisna işleme kodu eklerim. İyi bir tavsiye ile örtüştüğünü biliyorum ama gerçekte benim için çalışıyor ve bu sorun için daha iyi bir yol bilmiyorum.

Mike Wheat'ın cevabı ana noktaları oldukça iyi özetlese de başka bir cevap eklemek zorunda hissediyorum. Ben böyle düşünüyorum. Birden fazla şey yapan yöntemleriniz olduğunda, karmaşıklığı çoğaltırsınız, eklemezsiniz.

Başka bir deyişle, bir try catch içine sarılmış bir yöntemin iki olası sonucu vardır. İstisnai olmayan sonucunuz ve istisna sonucunuz var. Birçok yöntemle uğraşırken, bu katlanarak kavrayışın ötesine geçer.

Üstel olarak, eğer her yöntem iki farklı şekilde dallanırsa, başka bir yöntemi her çağırışınızda, önceki potansiyel sonuçların karesini alırsınız. Beş yöntem çağırdığınızda, en az 256 olası sonuç elde edersiniz. Bu karşılaştırın değil her yöntemde bir try / catch yapıyor ve sadece takip etmek tek yolu var.

Temelde ben böyle bakıyorum. Herhangi bir dallanma türünün aynı şeyi yaptığını iddia etmek cazip gelebilir, ancak deneme / yakalama özel bir durumdur, çünkü uygulamanın durumu temelde tanımsız hale gelir.

Kısacası, deneme / yakalama kodunu anlamak çok daha zor hale getirir.

Kodunuzun her bölümünü içeride saklamanıza gerek yoktur try-catch. try-catchBloğun ana kullanımı hata işleme ve programınızda hatalar / istisnalar almaktır. Bazı kullanımları try-catch-

1. Bir istisnayı işlemek istediğiniz yerde bu bloğu kullanabilirsiniz veya yazılı kod bloğunun bir istisna atabileceğini söyleyebilirsiniz.
2. Nesnelerinizi kullanıldıktan hemen sonra imha etmek istiyorsanız, try-catchbloğu kullanabilirsiniz .