İstisna işlemeyi ne zaman ve nasıl kullanmalıyım?

İstisna işlemeyi okuyorum. İstisna işlemenin ne olduğu hakkında biraz bilgi aldım, ancak birkaç sorum var:

1. Ne zaman bir istisna yapılmalı?
2. Bir istisna atmak yerine, hatayı belirtmek için bir dönüş değeri kullanabilir miyiz?
3. Tüm fonksiyonlarımı deneme-yakalama bloklarıyla korursam, performansı düşürmez mi?
4. İstisna işleme ne zaman kullanılır?
5. Bu projedeki her işlevin bir dene-yakala bloğu içerdiği bir proje gördüm (yani tüm işlevin içindeki kod, deneme-yakalama bloğu ile çevrilidir). Bu iyi bir uygulama mı?
6. Try-catch ve __try __except arasındaki fark nedir?

Okumalısınız olduğunu düşündüğüm istisnalar hakkında oldukça kapsamlı bir rehber:

İstisnalar ve hata işleme - C ++ SSS veya C ++ SSS lite

Genel bir kural olarak, programınız harici biryürütmeyi engelleyen sorun. Sunucudan veri alırsanız ve bu veriler geçersizse, bir istisna atın. Disk alanı dolu? Bir istisna atın. Kozmik ışınlar veri tabanını sorgulamanızı engeller mi? Bir istisna atın. Ancak kendi programınızın içinden bazı geçersiz veriler alırsanız - bir istisna atmayın. Sorununuz kendi kötü kodunuzdan kaynaklanıyorsa, buna karşı korunmak için ASSERT kullanmak daha iyidir. Programın üstesinden gelemediği sorunları belirlemek ve bunları kullanıcı hakkında anlatmak için istisna işlemesi gereklidir, çünkü kullanıcı bunları halledebilir. Ancak programınızdaki hatalar kullanıcının başa çıkabileceği bir şey değildir, bu nedenle programın çökmesi "answer_to_life_and_universe_ve_herything 42 değildir! Bu asla olmamalı !!!! 11" istisnasından daha azını söyleyecektir.

Onunla yararlı bir şey yapabileceğiniz bir istisna yakalayın, örneğin bir mesaj kutusu görüntüleyin. Kullanıcı girdisini bir şekilde işleyen bir işlevin içinde bir istisna yakalamayı tercih ederim. Örneğin, kullanıcı "Tüm hunamları yok et" düğmesine basar ve annihilateAllHunamsClicked () işlevinin içinde "yapamam" demek için bir try ... catch bloğu vardır. Hunamkind'in yok edilmesi düzinelerce ve düzinelerce işlevi çağırmayı gerektiren karmaşık bir işlem olsa da, yalnızca bir try ... catch vardır, çünkü bu bir kullanıcı için atomik bir işlemdir - tek bir tıklama. Her işlevdeki istisna kontrolleri gereksiz ve çirkin.

Ayrıca, RAII'ye yeterince aşina olmayı öneremem - yani, başlatılan tüm verilerin otomatik olarak yok edilmesini sağlamak için. Ve bu, yığın üzerinde olabildiğince çok başlatma yaparak elde edilebilir ve yığın üzerinde bir şeyi başlatmanız gerektiğinde, bir tür akıllı işaretçi kullanın. Yığın üzerinde başlatılan her şey, bir istisna atıldığında otomatik olarak yok edilecektir. C tarzı aptal işaretçiler kullanırsanız, bir istisna atıldığında bellek sızıntısı riskiyle karşı karşıya kalırsınız, çünkü istisnalar üzerine onları temizleyecek kimse yoktur (elbette, sınıfınızın üyeleri olarak C tarzı işaretçileri kullanabilirsiniz, ancak yıkıcıda halledilir).

İstisnalar, çeşitli durumlarda yararlıdır.

Birincisi, ön koşulu hesaplama maliyetinin çok yüksek olduğu bazı işlevler vardır, ön koşulun karşılanmadığı tespit edilirse, sadece hesaplamayı yapmak ve bir istisna dışında iptal etmek daha iyidir. Örneğin, tekil bir matrisi tersine çeviremezsiniz, ancak tekil olup olmadığını hesaplamak için çok pahalı olan determinantı hesaplarsınız: her halükarda işlev içinde yapılması gerekebilir, bu nedenle matrisi tersine çevirmeyi deneyin ve rapor edin bir istisna atarak yapamazsanız bir hata. Bu, olumsuz ön koşul kullanımı olarak temelde bir istisnadır .

Ayrıca, kodunuzun zaten karmaşık olduğu ve hata bilgilerini çağrı zincirinden geçirmenin zor olduğu başka durumlar da vardır. Bunun nedeni kısmen C ve C ++ 'nın bozuk veri yapısı modellerine sahip olmasıdır: başka, daha iyi yollar da vardır, ancak C ++ bunları desteklemez (Haskell'de monad kullanmak gibi). Bu kullanım temelde bunu doğru yapmaktan rahatsız olamam, bu yüzden bir istisna atacağım : doğru yol değil ama pratik.

Daha sonra istisnaların ana kullanımı vardır: bellek veya disk alanı gibi yeterli kaynaklar gibi harici ön koşullar veya değişmezler mevcut olmadığında rapor etmek. Bu durumda genellikle programı veya büyük bir alt bölümünü sonlandırırsınız ve istisna, sorunla ilgili bilgi aktarmanın iyi bir yoludur. C ++ İstisnaları, programın devam etmesini engelleyen hataları bildirmek için tasarlanmıştır .

C ++ dahil çoğu modern dilde kullanılan istisna işleme modelinin bozuk olduğu bilinmektedir . Çok fazla güçlü. Teorisyenler artık tamamen açık olan "bir şey fırlat" ve "belki ve belki yakala" modelinden daha iyi modeller geliştirdiler. Ayrıca, istisnaları sınıflandırmak için tür bilgisini kullanmak çok da iyi bir fikir değildi.

Yapabileceğiniz en iyi şey Yani orada gerçek bir hatadır ve ne zaman idareli, atış istisnalar başa başka bir yol olduğunda ve fırlatma noktasına mümkün olduğunca yakın istisnaları ölçülü bir şekilde atmaktır .

Sorununuz kendi kötü kodunuzdan kaynaklanıyorsa, buna karşı korunmak için ASSERT kullanmak daha iyidir. Programın üstesinden gelemediği sorunları belirlemek ve bunları kullanıcı hakkında anlatmak için istisna işleme gereklidir, çünkü kullanıcı bunları halledebilir. Ancak programınızdaki hatalar kullanıcının başa çıkabileceği bir şey değildir, bu nedenle programın çökmesi pek bir şey söylemez

Kabul edilen cevabın bu yönüne katılmıyorum . Bir iddia, bir istisna atmaktan daha iyi değildir. İstisnalar yalnızca çalışma zamanı hataları (veya "harici sorunlar") için uygunsa, ne işe yarar std::logic_error?

Mantık hatası, neredeyse tanımı gereği bir programın devam etmesini engelleyen koşul türüdür. Program mantıksal bir yapı ise ve bu mantığın etki alanı dışında bir koşul meydana gelirse, nasıl devam edebilir? Elinizden geldiğince girdiler toplayın ve bir istisna atın!

Önceki sanat yok gibi değil. std::vector, ancak birini adlandırmak gerekirse, bir mantık hatası istisnası atar std::out_of_range. Eğer standart kütüphane kullanma ve standart istisnaları yakalamak için üst düzey bir işleyici yoksa - çağırmak üzere yalnızca neyi () ve çıkış (3) - ardından programlar ani sessiz, fesih tabidir.

İddia makrosu çok daha zayıf bir korumadır. İyileşme yok. Diğer bir deyişle, bir hata ayıklama derlemesi çalıştırmıyorsanız, bu durumda yürütme olmaz . İddia makrosu, hesaplamanın bugünkünden 6 kat daha yavaş olduğu bir çağa aittir. Mantık hatalarını test etme zahmetine girecek, ancak önemli olduğunda bu testi kullanmayacaksanız, üretimde, kodunuza çok güvenmeniz iyi olur!

Standart kütüphane, mantık hatası istisnaları sağlar ve bunları kullanır. Bir sebepten dolayı oradalar: çünkü mantık hataları meydana gelir ve istisnaidir. Sırf C'nin iddiaları öne çıkarması, bir istisna işi çok daha iyi ele aldığında, böylesine ilkel (ve tartışmasız, yararsız) bir mekanizmaya güvenmek için bir neden değildir.

Bunun için en iyi okuma

İstisna yönetimi son on bir buçuk yılda çok konuşuldu. Bununla birlikte, istisnaların nasıl düzgün bir şekilde ele alınacağına dair genel bir fikir birliğine rağmen, kullanım konusunda bir bölünme var olmaya devam ediyor. Hatalı istisna işleme, tespit edilmesi ve önlenmesi kolaydır ve basit bir kod (ve geliştirici) kalite metriğidir. Mutlak kuralların yakın fikirli veya abartılı olduğunu biliyorum, ancak genel bir kural olarak, dene / yakala kullanmamalısın

http://codebetter.com/karlseguin/2010/01/25/don-t-use-try-catch/

1. Sonuç olarak veya problemin ortasında bir yerde bir istisna olma olasılığı olduğunda koda bir istisna kontrolü eklenir.

2. Try-catch bloğunu yalnızca gerekli olduğu durumlarda kullanın. Her bir dene-yakala bloğunun kullanımı, kodun optimizasyonunu kesinlikle azaltan ekstra bir koşul kontrolüne eklenir.

3. _try_except'in geçerli bir değişken adı olduğunu düşünüyorum ....

Temel fark şudur:

1. Biri sizin için hata işlemeyi yapar.

2. biri kendininkini yapmaktır.

   • Örneğin, yapabileceğiniz bir ifadeniz var 0 divide error. Try catch kullanmak 1.hata oluştuğunda size yardımcı olacaktır. Veya bir ihtiyaç if a==0 then..içinde2.

   • Eğer istisnayı yakalamaya errorçalışmazsanız , daha hızlı olduğunu sanmıyorum, sadece basitçe baypas edin, eğer meydana gelirse threwbir dış işleyiciye olacaktır.

Kendinizi teslim etmek, sorunun daha ileri gitmemesi ve çoğu durumda hızda avantaj sağlamanız anlamına gelir, ancak her zaman değil.

Önerin: Sadece basit ve mantıklı bir durumda kendinizle ilgilenin.

Çoğu C / C ++ sadeliği, istisnaları tamamen caydırır. Ana eleştiriler:

1. Yavaş - Tabii ki gerçekten "yavaş" değil. Ancak, saf c / c ++ ile karşılaştırıldığında, oldukça fazla ek yük vardır.
2. Hatalar sunar - İstisnaları doğru şekilde işlemezseniz, istisnayı atan işlevdeki temizleme kodunu gözden kaçırabilirsiniz.

Bunun yerine, bir işlevi her çağırdığınızda dönüş değerini / hata kodunu kontrol edin.