Devo usare uno specificatore di eccezione in C ++?

In C ++, è possibile specificare che una funzione può o non può generare un'eccezione utilizzando uno specificatore di eccezione. Per esempio:

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

Sono dubbioso sull'utilizzo effettivo di loro a causa di quanto segue:

1. Il compilatore non impone gli specificatori di eccezioni in modo rigoroso, quindi i vantaggi non sono grandi. Idealmente, vorresti ricevere un errore di compilazione.
2. Se una funzione viola uno specificatore di eccezione, penso che il comportamento standard sia terminare il programma.
3. In VS.Net, tratta lancio (X) come lancio (...), quindi l'aderenza allo standard non è forte.

Pensi che dovrebbero essere usati gli specificatori di eccezione?
Rispondi con "sì" o "no" e fornisci alcuni motivi per giustificare la tua risposta.

No.

Ecco alcuni esempi di perché:

1. Il codice del modello è impossibile da scrivere con le specifiche di eccezione,

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

   Le copie potrebbero generare, il passaggio di parametri potrebbe generare e x()potrebbe generare un'eccezione sconosciuta.

2. Le specifiche di eccezione tendono a vietare l'estensibilità.

   virtual void open() throw( FileNotFound );

   potrebbe evolversi in

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

   Potresti davvero scriverlo come

   throw( ... )

   Il primo non è estensibile, il secondo è troppo ambizioso e il terzo è davvero quello che intendi quando scrivi funzioni virtuali.

3. Codice precedente

   Quando scrivi codice che si basa su un'altra libreria, non sai davvero cosa potrebbe fare quando qualcosa va terribilmente storto.

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

   gterminerà, quando lib_f()lancia. Questo (nella maggior parte dei casi) non è quello che vuoi veramente. std::terminate()non dovrebbe mai essere chiamato. È sempre meglio lasciare che l'applicazione si blocchi con un'eccezione non gestita, da cui è possibile recuperare una traccia dello stack, piuttosto che morire silenziosamente / violentemente.

4. Scrivi codice che restituisca errori comuni e lanci in occasioni eccezionali.

   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;
   }

Tuttavia, quando la tua libreria genera solo le tue eccezioni, puoi utilizzare le specifiche delle eccezioni per dichiarare il tuo intento.

Evita le specifiche di eccezione in C ++. Le ragioni che fornisci nella tua domanda sono un buon inizio per il perché.

Vedi Herb Sutter's "Uno sguardo pragmatico alle specifiche delle eccezioni" di .

Penso che gli specificatori di eccezione standard ad eccezione della convenzione (per C ++)
fossero un esperimento nello standard C ++ che per lo più fallì.
L'eccezione è che lo specificatore no throw è utile, ma dovresti anche aggiungere internamente il blocco try catch appropriato per assicurarti che il codice corrisponda allo specificatore. Herb Sutter ha una pagina sull'argomento. Gotch 82

Inoltre, penso che valga la pena descrivere le garanzie di eccezione.

Questi sono fondamentalmente la documentazione su come lo stato di un oggetto è influenzato dalle eccezioni che escono da un metodo su quell'oggetto. Sfortunatamente non vengono applicati o altrimenti menzionati dal compilatore.
Boost ed eccezioni

Garanzie di eccezione

Nessuna garanzia:

Non vi è alcuna garanzia sullo stato dell'oggetto dopo che un'eccezione è sfuggita a un metodo
In queste situazioni l'oggetto non dovrebbe più essere utilizzato.

Garanzia di base:

In quasi tutte le situazioni questa dovrebbe essere la garanzia minima fornita da un metodo.
Ciò garantisce che lo stato dell'oggetto sia ben definito e possa ancora essere utilizzato in modo coerente.

Garanzia forte: (nota anche come garanzia transazionale)

Ciò garantisce che il metodo verrà completato correttamente
o verrà generata un'eccezione e lo stato degli oggetti non cambierà.

Nessuna garanzia di tiro:

Il metodo garantisce che non sia consentita la propagazione delle eccezioni al di fuori del metodo.
Tutti i distruttori dovrebbero fornire questa garanzia.
| NB Se un'eccezione sfugge a un distruttore mentre un'eccezione si sta già propagando
| l'applicazione verrà chiusa

gcc emetterà avvisi quando violate le specifiche di eccezione. Quello che faccio è utilizzare le macro per utilizzare le specifiche delle eccezioni solo in modalità "lint" compilare espressamente per verificare che le eccezioni siano d'accordo con la mia documentazione.

L'unico identificatore di eccezione utile è "throw ()", come in "non lancia".

Le specifiche delle eccezioni non sono strumenti straordinariamente utili in C ++. Tuttavia, c'è / un buon uso per loro, se combinati con std :: inaspettato.

Quello che faccio in alcuni progetti è codice con specifiche di eccezione, quindi chiamo set_unexpected () con una funzione che genererà un'eccezione speciale del mio progetto. Questa eccezione, al momento della costruzione, ottiene un backtrace (in un modo specifico della piattaforma) ed è derivato da std :: bad_exception (per consentirne la propagazione se lo si desidera). Se provoca una chiamata a terminate (), come fa di solito, il backtrace viene stampato da what () (così come l'eccezione originale che lo ha causato; non è difficile trovarlo) e quindi ottengo informazioni su dove si trovava il mio contratto violata, ad esempio quale eccezione imprevista della libreria è stata generata.

Se lo faccio, non permetto mai la propagazione delle eccezioni della libreria (eccetto quelle std) e ricavo tutte le mie eccezioni da std :: exception. Se una libreria decide di lanciare, catturerò e convertirò nella mia gerarchia, permettendomi di controllare sempre il codice. Le funzioni basate su modelli che chiamano funzioni dipendenti dovrebbero evitare le specifiche di eccezione per ovvie ragioni; ma è comunque raro avere un'interfaccia di funzione basata su modelli con il codice della libreria (e poche librerie usano davvero i modelli in modo utile).

Se stai scrivendo codice che verrà utilizzato da persone che preferirebbero guardare la dichiarazione della funzione piuttosto che qualsiasi commento attorno ad essa, una specifica dirà loro quali eccezioni potrebbero voler catturare.

Altrimenti non trovo particolarmente utile utilizzare altro se non throw()per indicare che non genera eccezioni.

No. Se li usi e viene generata un'eccezione che non hai specificato, dal tuo codice o dal codice chiamato dal tuo codice, il comportamento predefinito è terminare prontamente il tuo programma.

Inoltre, credo che il loro uso sia stato deprecato nelle attuali bozze dello standard C ++ 0x.

Una specifica "throw ()" consente al compilatore di eseguire alcune ottimizzazioni durante l'analisi del flusso di codice se sa che la funzione non genererà mai un'eccezione (o almeno promette di non lanciare mai un'eccezione). Larry Osterman ne parla brevemente qui:

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

Generalmente non userei specificatori di eccezioni. Tuttavia, nei casi in cui se dalla funzione in questione derivasse qualsiasi altra eccezione, il programma non sarebbe definitivamente in grado di correggere , allora può essere utile. In tutti i casi, assicurati di documentare chiaramente quali eccezioni ci si possono aspettare da quella funzione.

Sì, il comportamento previsto di un'eccezione non specificata generata da una funzione con specificatori di eccezione è chiamare terminate ().

Noterò anche che Scott Meyers affronta questo argomento in C ++ più efficace. Il suo Effective C ++ e More Effective C ++ sono libri altamente raccomandati.

Sì, se ti interessa la documentazione interna. O magari scrivere una libreria che altri useranno, in modo che possano raccontare cosa succede senza consultare la documentazione. Lanciare o non lanciare può essere considerato parte dell'API, quasi come il valore restituito.

Sono d'accordo, non sono veramente utili per imporre la correttezza dello stile Java nel compilatore, ma è meglio di niente o commenti casuali.

Possono essere utili per i test unitari in modo che quando si scrivono i test si sappia cosa aspettarsi che la funzione lanci quando fallisce, ma non c'è alcuna applicazione che li circonda nel compilatore. Penso che siano codice extra che non è necessario in C ++. Qualunque cosa tu scelga, tutto ciò di cui dovresti essere sicuro è che segui lo stesso standard di codifica in tutto il progetto e nei membri del team in modo che il tuo codice rimanga leggibile.

Dall'articolo:

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

"È risaputo che è impossibile scrivere un contenitore generico sicuro rispetto alle eccezioni." Questa affermazione è spesso ascoltata con riferimento a un articolo di Tom Cargill [4] in cui esplora il problema della sicurezza dalle eccezioni per un modello di stack generico. Nel suo articolo, Cargill solleva molte domande utili, ma sfortunatamente non riesce a presentare una soluzione al suo problema.1 Conclude suggerendo che una soluzione potrebbe non essere possibile. Sfortunatamente, il suo articolo è stato letto da molti come una "prova" di quella speculazione. Da quando è stato pubblicato, ci sono stati molti esempi di componenti generici sicuri dalle eccezioni, tra cui i contenitori di librerie standard C ++.

E in effetti posso pensare a modi per rendere sicure le eccezioni delle classi modello. A meno che tu non abbia il controllo su tutte le sottoclassi, potresti comunque avere un problema. Per fare questo si potrebbe creare typedef nelle proprie classi che definiscono le eccezioni lanciate da varie classi template. Questo credo che il problema sia come sempre affrontarlo in seguito invece di progettarlo dall'inizio, e penso che sia questo sovraccarico il vero ostacolo.

Specifiche di eccezione = spazzatura, chiedi a qualsiasi sviluppatore Java di età superiore ai 30 anni