Devo ereditare da std :: exception?

Ho visto almeno una fonte affidabile (una classe C ++ che ho preso) raccomandare che le classi di eccezioni specifiche dell'applicazione in C ++ dovrebbero ereditare da std::exception. Non sono chiaro i vantaggi di questo approccio.

In C # le ragioni per ereditare da ApplicationExceptionsono chiare: ottieni una manciata di metodi, proprietà e costruttori utili e devi solo aggiungere o sovrascrivere ciò di cui hai bisogno. Con std::exceptionsembra che tutto ciò che ottieni sia un what()metodo per sovrascrivere, che potresti anche creare tu stesso.

Quindi quali sono i vantaggi, se ce ne sono, dell'utilizzo std::exceptioncome classe base per la mia classe di eccezione specifica per l'applicazione? Ci sono buone ragioni per non ereditare std::exception?

Il vantaggio principale è che il codice che utilizza le tue classi non deve conoscere il tipo esatto di ciò che stai facendo throw, ma può solo catchil file std::exception.

Modifica: come hanno notato Martin e altri, in realtà si desidera derivare da una delle sottoclassi std::exceptiondichiarate <stdexcept>nell'intestazione.

Il problema std::exceptionè che non esiste un costruttore (nelle versioni conformi allo standard) che accetti un messaggio.

Di conseguenza preferisco derivare da std::runtime_error. Questo è derivato da, std::exceptionma i suoi costruttori consentono di passare una stringa C o std::stringa al costruttore che verrà restituito (come a char const*) quando what()viene chiamato.

Il motivo per ereditare da std::exceptionè la sua classe base "standard" per le eccezioni, quindi è naturale per altre persone in un team, ad esempio, aspettarselo e catturare la base std::exception.

Se stai cercando comodità, puoi ereditare da std::runtime_errorquel fornisce il std::stringcostruttore.

Una volta ho partecipato alla pulizia di una grande base di codice in cui gli autori precedenti avevano lanciato int, HRESULTS, std :: string, char *, classi casuali ... cose diverse ovunque; basta nominare un tipo e probabilmente è stato lanciato da qualche parte. E nessuna classe base comune. Credimi, le cose erano molto più ordinate una volta arrivati ​​al punto che tutti i tipi lanciati avevano una base comune che potevamo catturare e sapere che nulla sarebbe passato. Quindi, per favore, fai un favore a te stesso (e a coloro che dovranno mantenere il tuo codice in futuro) e fallo in questo modo dall'inizio.

Dovresti ereditare da boost :: exception . Fornisce molte più funzionalità e modi ben compresi per trasportare dati aggiuntivi ... ovviamente, se non stai usando Boost , ignora questo suggerimento.

Sì, dovresti derivare da std::exception.

Altri hanno risposto che std::exceptionha il problema che non è possibile passare un messaggio di testo, tuttavia in genere non è una buona idea tentare di formattare un messaggio utente nel punto in cui viene lanciato. Utilizzare invece l'oggetto eccezione per trasportare tutte le informazioni rilevanti al sito di cattura che può quindi formattare un messaggio intuitivo.

Il motivo per cui potresti voler ereditare da std::exceptionè perché ti consente di lanciare un'eccezione che viene catturata in base a quella classe, ovvero:

class myException : public std::exception { ... };
try {
    ...
    throw myException();
}
catch (std::exception &theException) {
    ...
}

C'è un problema con l'ereditarietà di cui dovresti essere a conoscenza è il sezionamento degli oggetti. Quando scrivi throw e;un'espressione di lancio inizializza un oggetto temporaneo, chiamato oggetto eccezione, il cui tipo viene determinato rimuovendo qualsiasi qualificatore cv di primo livello dal tipo statico dell'operando di throw. Potrebbe non essere quello che ti aspetti. Esempio di problema che potresti trovare qui .

Non è un argomento contro l'ereditarietà, è solo un'informazione "da conoscere".

Differenza: std :: runtime_error vs std :: exception ()

Sia che si dovrebbe ereditare da essa o meno spetta a voi. Lo standard std::exceptionei suoi discendenti standard propongono una possibile struttura gerarchica delle eccezioni (divisione in logic_errorsubhierarchy e runtime_errorsubhierarchy) e una possibile interfaccia dell'oggetto eccezione. Se ti piace, usalo. Se per qualche motivo hai bisogno di qualcosa di diverso, definisci il tuo framework di eccezioni.

Poiché la lingua lancia già std :: exception, è necessario prenderla comunque per fornire una segnalazione degli errori decente. Puoi anche usare lo stesso trucco per tutte le tue eccezioni impreviste. Inoltre, quasi tutte le librerie che generano eccezioni le deriverebbero da std :: exception.

In altre parole, è l'uno o l'altro

catch (...) {cout << "Unknown exception"; }

o

catch (const std::exception &e) { cout << "unexpected exception " << e.what();}

E la seconda opzione è decisamente migliore.

Se tutte le tue possibili eccezioni derivano da std::exception, il tuo blocco di cattura può semplicemente catch(std::exception & e)essere certo di catturare tutto.

Dopo aver acquisito l'eccezione, puoi utilizzare quel whatmetodo per ottenere maggiori informazioni. C ++ non supporta la digitazione anatra, quindi un'altra classe con un whatmetodo richiederebbe un catch diverso e un codice diverso per usarlo.

La prima domanda è se derivare da qualsiasi tipo di eccezione standard o meno. In questo modo si abilita un singolo gestore di eccezioni per tutte le eccezioni della libreria standard e la propria, ma incoraggia anche tali gestori catch-them-all. Il problema è che si dovrebbero catturare solo le eccezioni che si sa come gestire. In main (), ad esempio, catturare tutte le eccezioni std :: è probabilmente una buona cosa se la stringa what () verrà registrata come ultima risorsa prima di uscire. Altrove, tuttavia, è improbabile che sia una buona idea.

Una volta deciso se derivare da un tipo di eccezione standard o meno, la domanda è quale dovrebbe essere la base. Se la tua applicazione non necessita di i18n, potresti pensare che la formattazione di un messaggio sul sito della chiamata sia altrettanto buono che salvare le informazioni e generare il messaggio sul sito della chiamata. Il problema è che il messaggio formattato potrebbe non essere necessario. È meglio utilizzare uno schema di generazione di messaggi pigri, magari con memoria preallocata. Quindi, se il messaggio è necessario, verrà generato all'accesso (e, possibilmente, memorizzato nella cache nell'oggetto eccezione). Pertanto, se il messaggio viene generato quando viene lanciato, è necessario un derivato std :: exception, come std :: runtime_error come classe base. Se il messaggio viene generato pigramente, std :: exception è la base appropriata.

Un altro motivo per le eccezioni sottoclasse è un aspetto di progettazione migliore quando si lavora su grandi sistemi incapsulati. Puoi riutilizzarlo per cose come messaggi di convalida, query degli utenti, errori irreversibili del controller e così via. Piuttosto che riscrivere o riagganciare tutta la tua convalida come i messaggi, puoi semplicemente "catturarla" nel file sorgente principale, ma lanciare l'errore ovunque nell'intero insieme di classi.

Ad esempio, un'eccezione fatale terminerà il programma, un errore di convalida cancellerà solo lo stack e una query dell'utente farà una domanda all'utente finale.

In questo modo puoi anche riutilizzare le stesse classi ma su interfacce diverse. Ad esempio, un'applicazione Windows può utilizzare una finestra di messaggio, un servizio Web mostrerà html e il sistema di reporting lo registrerà e così via.

Sebbene questa domanda sia piuttosto vecchia e abbia già ricevuto molte risposte, voglio solo aggiungere una nota su come gestire correttamente le eccezioni in C ++ 11, dal momento che mi manca continuamente nelle discussioni sulle eccezioni:

Usa std::nested_exceptionestd::throw_with_nested

È descritto su StackOverflow qui e qui , come puoi ottenere un backtrace sulle tue eccezioni all'interno del tuo codice senza bisogno di un debugger o di un log complicato, semplicemente scrivendo un gestore di eccezioni appropriato che rilancerà le eccezioni nidificate.

Dato che puoi farlo con qualsiasi classe di eccezione derivata, puoi aggiungere molte informazioni a tale backtrace! Puoi anche dare un'occhiata al mio MWE su GitHub , dove un backtrace sarebbe simile a questo:

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"

Non è nemmeno necessario creare una sottoclasse std::runtime_errorper ottenere molte informazioni quando viene generata un'eccezione.

L'unico vantaggio che vedo nella sottoclasse (invece di usare solo std::runtime_error) è che il tuo gestore di eccezioni può catturare la tua eccezione personalizzata e fare qualcosa di speciale. Per esempio:

try
{
  // something that may throw
}
catch( const MyException & ex )
{
  // do something specialized with the
  // additional info inside MyException
}
catch( const std::exception & ex )
{
  std::cerr << ex.what() << std::endl;
}
catch( ... )
{
  std::cerr << "unknown exception!" << std::endl;
}