C ++ 'da bir istisna tanımlayıcı kullanmalı mıyım?

C ++ 'da, bir işlevin bir istisna belirticisi kullanarak bir istisna atıp atamayacağını belirtebilirsiniz. Örneğin:

void foo() throw(); // guaranteed not to throw an exception
void bar() throw(int); // may throw an exception of type int
void baz() throw(...); // may throw an exception of some unspecified type

Aşağıdakilerden dolayı bunları gerçekten kullanmak konusunda şüpheliyim:

1. Derleyici, istisna belirleyicileri herhangi bir titiz şekilde gerçekten zorlamaz, bu nedenle faydalar büyük değildir. İdeal olarak, bir derleme hatası almak istersiniz.
2. Bir işlev bir istisna tanımlayıcısını ihlal ederse, standart davranışın programı sonlandırmak olduğunu düşünüyorum.
3. VS.Net'te, throw (X) 'i fırlatma (...) olarak ele alır, bu nedenle standarda bağlılık güçlü değildir.

İstisna tanımlayıcıların kullanılması gerektiğini düşünüyor musunuz?
Lütfen "evet" veya "hayır" olarak yanıtlayın ve cevabınızı gerekçelendirmek için bazı nedenler belirtin.

Hayır.

İşte bunun birkaç örneği:

1. İstisna özellikleriyle şablon kodu yazmak imkansızdır,

   template<class T>
   void f( T k )
   {
        T x( k );
        x.x();
   }

   Kopyalar atabilir, geçen parametre atabilir ve x()bazı bilinmeyen istisnalar atabilir.

2. İstisna spesifikasyonlar, genişletilebilirliği yasaklama eğilimindedir.

   virtual void open() throw( FileNotFound );

   dönüşebilir

   virtual void open() throw( FileNotFound, SocketNotReady, InterprocessObjectNotImplemented, HardwareUnresponsive );

   Bunu gerçekten şu şekilde yazabilirsin

   throw( ... )

   İlki genişletilebilir değil, ikincisi aşırı hırslı ve üçüncüsü, sanal işlevler yazarken gerçekten kastettiğin şey.

3. Eski kod

   Başka bir kitaplığa dayanan bir kod yazdığınızda, bir şeyler korkunç bir şekilde ters gittiğinde bunun ne işe yarayacağını gerçekten bilemezsiniz.

   int lib_f();
   
   void g() throw( k_too_small_exception )
   { 
      int k = lib_f();
      if( k < 0 ) throw k_too_small_exception();
   }

   gatıldığında sona erecek lib_f(). Bu (çoğu durumda) gerçekten istediğiniz şey değildir. std::terminate()asla çağrılmamalıdır. Sessizce / şiddetle ölmektense, yığın izleme alabileceğiniz işlenmemiş bir istisna ile uygulamanın çökmesine izin vermek her zaman daha iyidir.

4. Yaygın hataları döndüren ve istisnai durumlarda fırlatan kod yazın.

   Error e = open( "bla.txt" );
   if( e == FileNotFound )
       MessageUser( "File bla.txt not found" );
   if( e == AccessDenied )
       MessageUser( "Failed to open bla.txt, because we don't have read rights ..." );
   if( e != Success )
       MessageUser( "Failed due to some other error, error code = " + itoa( e ) );
   
   try
   {
      std::vector<TObj> k( 1000 );
      // ...
   }
   catch( const bad_alloc& b )
   { 
      MessageUser( "out of memory, exiting process" );
      throw;
   }

Yine de, kitaplığınız kendi istisnalarınızı ortaya çıkardığında, amacınızı belirtmek için istisna özelliklerini kullanabilirsiniz.

C ++ 'da istisna belirtimlerinden kaçının. Sorunuzda verdiğiniz nedenler, neden için oldukça iyi bir başlangıçtır.

Herb Sutter'ın "İstisna Özelliklerine Pragmatik Bir Bakış" sayfasına bakın .

Bence standart hariç kongre (C ++ için)
İstisna tanımlayıcıları, C ++ standardında çoğunlukla başarısız olan bir deneydi.
Bunun istisnası, no throw belirticisinin yararlı olmasıdır, ancak kodun belirticiyle eşleştiğinden emin olmak için dahili olarak uygun try catch bloğunu eklemeniz gerekir. Herb Sutter'ın konuyla ilgili bir sayfası var. Gotch 82

Ek olarak, İstisna Garantilerini açıklamaya değer olduğunu düşünüyorum.

Bunlar temelde, bir nesnenin durumunun, o nesne üzerindeki bir yöntemden kaçan istisnalardan nasıl etkilendiğine ilişkin belgelerdir. Maalesef derleyici tarafından zorunlu tutulmuyor veya başka bir şekilde bahsedilmiyor.
Güçlendirme ve İstisnalar

İstisna Garantileri

Garanti yok:

Bir özel durum bir yöntemden kaçtıktan sonra nesnenin durumu hakkında hiçbir garanti yoktur
. Bu durumlarda nesne artık kullanılmamalıdır.

Temel Garanti:

Neredeyse tüm durumlarda bu, bir yöntemin sağladığı minimum garanti olmalıdır.
Bu, nesnenin durumunun iyi tanımlanmasını ve tutarlı bir şekilde kullanılabilmesini garanti eder.

Güçlü Garanti: (diğer adıyla İşlem Garantisi)

Bu, yöntemin başarılı
bir şekilde tamamlanacağını veya bir İstisna atılacağını ve nesnelerin durumunun değişmeyeceğini garanti eder .

Atma Garantisi Yok:

Yöntem, hiçbir istisnanın yöntemden çıkmasına izin verilmediğini garanti eder.
Tüm yıkıcılar bu garantiyi vermelidir.
| NB Bir istisna hali hazırda yayılırken bir istisna yıkıcıdan kaçarsa
| uygulama sona erecek

gcc, istisna belirtimlerini ihlal ettiğinizde uyarılar verir. Yaptığım şey, istisnaların benim belgelerimle uyuştuğundan emin olmak için açıkça kontrol etmek amacıyla istisna belirtimlerini yalnızca "tüy bırakmayan" mod derlemesinde kullanmak için makroları kullanmaktır.

Tek kullanışlı istisna belirticisi, "atmıyor" daki gibi "throw ()" dir.

İstisna belirtimleri, C ++ 'da harika kullanışlı araçlar değildir. Bununla birlikte, std :: unexpected ile birleştirilirse, onlar için iyi bir kullanım vardır / vardır / vardır.

Bazı projelerde yaptığım şey, istisna özellikli kod ve ardından kendi tasarımımın özel bir istisnasını atacak bir fonksiyonla set_unexpected () 'ı çağırmaktır. Bu istisna, oluşturulduktan sonra bir geri izleme alır (platforma özgü bir şekilde) ve std :: bad_exception'dan türetilir (istenirse yayılmasına izin vermek için). Bir sonlandırma () çağrısına neden olursa, genellikle olduğu gibi, geri izleme ne () tarafından yazdırılır (ve buna neden olan orijinal istisna; bunu bulmak zor değil) ve böylece sözleşmemin nerede olduğu hakkında bilgi alırım beklenmedik kütüphane istisnası gibi ihlal edildi.

Bunu yaparsam, kütüphane istisnalarının yayılmasına (standart olanlar hariç) asla izin vermem ve tüm istisnalarımı std :: exception'dan türetmem. Bir kütüphane atmaya karar verirse, her zaman kodu kontrol etmeme izin verecek şekilde yakalayıp kendi hiyerarşime dönüşeceğim. Bağımlı işlevleri çağıran şablonlu işlevler, bariz nedenlerle istisna belirtimlerinden kaçınmalıdır; ancak yine de kütüphane kodu ile şablonlu bir işlev arayüzüne sahip olmak nadirdir (ve birkaç kütüphane gerçekten şablonları yararlı bir şekilde kullanır).

İşlev bildirimine etrafındaki herhangi bir yorum yerine bakmayı tercih eden kişiler tarafından kullanılacak bir kod yazıyorsanız, o zaman bir belirtim onlara hangi istisnaları yakalamak isteyebileceklerini söyleyecektir.

Aksi takdirde throw(), herhangi bir istisna oluşturmadığını belirtmekten başka bir şey kullanmayı özellikle yararlı bulmuyorum .

Hayır. Bunları kullanırsanız ve kodunuz veya kodunuz tarafından çağrılan kod tarafından belirtmediğiniz bir istisna atılırsa, varsayılan davranış programınızı derhal sonlandırmaktır.

Ayrıca, C ++ 0x standardının mevcut taslaklarında kullanımlarının kullanımdan kaldırıldığına inanıyorum.

Bir "throw ()" belirtimi, derleyicinin kod akışı analizi yaparken, işlevin hiçbir zaman bir istisna atmayacağını biliyorsa (veya en azından bir istisna atmayacağına söz veriyorsa) bazı optimizasyonları gerçekleştirmesine izin verir. Larry Osterman burada kısaca bundan bahsediyor:

http://blogs.msdn.com/larryosterman/archive/2006/03/22/558390.aspx

Genellikle istisna tanımlayıcıları kullanmam. Ancak, herhangi bir başka istisna program kesin mümkün olacağını söz konusu işlevinden gelmek olsaydı durumlarda düzeltmek , o zaman yararlı olabilir. Her durumda, o işlevden hangi istisnaların beklenebileceğini açıkça belgelediğinizden emin olun.

Evet, belirtilmemiş bir istisnanın istisna belirleyicileri olan bir işlevden atılması beklenen davranışı terminate () 'yi çağırmaktır.

Ayrıca Scott Meyers'in bu konuya Daha Etkili C ++ 'da değindiğini de not edeceğim. Etkili C ++ ve Daha Etkili C ++, şiddetle tavsiye edilen kitaplardır.

Evet, dahili dokümantasyonla ilgileniyorsanız. Ya da belki başkalarının kullanacağı bir kitaplık yazmak, böylece belgelere başvurmadan ne olacağını anlatabilirler. Atma veya atmama, neredeyse dönüş değeri gibi API'nin bir parçası olarak kabul edilebilir.

Derleyicide Java stilinin doğruluğunu zorlamak için gerçekten yararlı olmadıklarına katılıyorum, ancak hiç yoktan veya gelişigüzel yorumlardan daha iyidir.

Birim testi için yararlı olabilirler, böylece testler yazarken işlevin başarısız olduğunda ne yapmasını bekleyeceğinizi bilirsiniz, ancak derleyicide bunları çevreleyen bir zorlama yoktur. C ++ 'da gerekli olmayan ekstra kodlar olduklarını düşünüyorum. Emin olmanız gereken her şeyi seçerseniz, kodunuzun okunabilir kalması için proje ve ekip üyeleri genelinde aynı kodlama standardını takip etmenizdir.

Makaleden:

http://www.boost.org/community/exception_safety.html

"İstisnai durumda güvenli bir genel kapsayıcı yazmanın imkansız olduğu iyi bilinmektedir." Bu iddia genellikle Tom Cargill'in [4] genel bir yığın şablonu için istisna güvenliği sorununu araştırdığı bir makaleye atıfta bulunularak duyulur. Cargill makalesinde birçok yararlı soruyu gündeme getiriyor, ancak maalesef sorununa bir çözüm sunamıyor.1 Bir çözümün mümkün olmayabileceğini öne sürerek bitiriyor. Ne yazık ki makalesi birçok kişi tarafından bu spekülasyonun "kanıtı" olarak okundu. Yayınlandığından bu yana, aralarında C ++ standart kitaplık kapsayıcılarının da bulunduğu, istisnai durum korumalı jenerik bileşenlere dair birçok örnek olmuştur.

Ve gerçekten de şablon sınıflarını güvenli hale getirmenin yollarını düşünebilirim. Tüm alt sınıflar üzerinde kontrol sahibi olmadığınız sürece, yine de bir sorununuz olabilir. Bunu yapmak için, sınıflarınızda çeşitli şablon sınıfları tarafından atılan istisnaları tanımlayan typedef'ler oluşturabilirsiniz. Bu, sorunun baştan tasarlamak yerine her zaman olduğu gibi sonradan ele almak olduğunu düşünüyor ve bence asıl engel bu ek yük.

İstisna özellikler = çöp, 30 yaşın üzerindeki herhangi bir Java geliştiricisine sorun