Is `catch (...) {lancio; } `una cattiva pratica?

Anche se concordo sul fatto che catturare ... senza ricrescere sia effettivamente sbagliato, tuttavia credo che usare costrutti come questo:

try
{
  // Stuff
}
catch (...)
{
  // Some cleanup
  throw;
}

È accettabile nei casi in cui RAII non è applicabile . (Per favore, non chiedere ... non tutti nella mia azienda amano la programmazione orientata agli oggetti e RAII è spesso vista come "materiale scolastico inutile" ...)

I miei colleghi dicono che dovresti sempre sapere quali eccezioni devono essere lanciate e che puoi sempre usare costrutti come:

try
{
  // Stuff
}
catch (exception_type1&)
{
  // Some cleanup
  throw;
}
catch (exception_type2&)
{
  // Some cleanup
  throw;
}
catch (exception_type3&)
{
  // Some cleanup
  throw;
}

Esiste una buona pratica ben ammessa riguardo a queste situazioni?

I miei colleghi dicono che dovresti sempre sapere quali eccezioni devono essere lanciate [...]

Il tuo collega, odio dirlo, ovviamente non ha mai lavorato su biblioteche di uso generale.

Come in tutto il mondo può una classe come std::vectoranche fingere di sapere quali sono i costruttori di copia getterà, pur garantendo la sicurezza eccezione?

Se sapessi sempre cosa farebbe la chiamata in fase di compilazione, il polimorfismo sarebbe inutile! A volte l' intero obiettivo è quello di sottrarre ciò che accade a un livello inferiore, quindi in particolare non vuoi sapere cosa sta succedendo!

Quello che sembra essere catturato è l'inferno specifico di qualcuno che cerca di avere la sua torta e mangiarla anche lei.

RAII ed eccezioni sono progettate per andare di pari passo. RAII è il mezzo con cui non è necessario scrivere molte catch(...)istruzioni per eseguire la pulizia. Accadrà automaticamente, ovviamente. E le eccezioni sono l'unico modo per lavorare con oggetti RAII, perché i costruttori possono solo riuscire o lanciare (o mettere l'oggetto in uno stato di errore, ma chi lo vuole?).

Una catchdichiarazione può fare una delle due cose: gestire un errore o di circostanza eccezionale, o fare il lavoro di pulizia. A volte fa entrambe le cose, ma ogni catchaffermazione esiste per fare almeno una di queste.

catch(...)non è in grado di gestire correttamente le eccezioni. Non sai quale sia l'eccezione; non è possibile ottenere informazioni sull'eccezione. Non hai assolutamente altre informazioni oltre al fatto che un'eccezione è stata generata da qualcosa all'interno di un determinato blocco di codice. L'unica cosa legittima che puoi fare in un blocco del genere è fare pulizia. E questo significa ripetere l'eccezione alla fine della pulizia.

Ciò che RAII ti offre in merito alla gestione delle eccezioni è la pulizia gratuita. Se tutto è incapsulato correttamente in RAII, allora tutto verrà adeguatamente ripulito. Non è più necessario che le catchistruzioni eseguano la pulizia. In tal caso, non c'è motivo di scrivere una catch(...)dichiarazione.

Quindi concordo sul fatto che catch(...)è per lo più malvagio ... provvisoriamente .

Tale disposizione è l'uso corretto di RAII. Perché senza di essa, è necessario essere in grado di fare certa pulizia. Non c'è modo di aggirarlo; devi essere in grado di fare un lavoro di pulizia. Devi essere in grado di assicurarti che il lancio di un'eccezione lascerà il codice in uno stato ragionevole. Ed catch(...)è uno strumento vitale per farlo.

Non puoi averne uno senza l'altro. Non si può dire che sia RAII e catch(...) sono cattivi. Hai bisogno di almeno uno di questi; in caso contrario, non sei sicuro per le eccezioni.

Ovviamente, c'è un uso valido, anche se raro, catch(...)che nemmeno la RAII può bandire: ottenere un exception_ptrinoltro a qualcun altro. In genere tramite promise/futureun'interfaccia simile o simile.

I miei colleghi dicono che dovresti sempre sapere quali eccezioni devono essere lanciate e che puoi sempre usare costrutti come:

Il tuo collega è un idiota (o semplicemente terribilmente ignorante). Questo dovrebbe essere immediatamente ovvio a causa della quantità di codice copia e incolla che sta suggerendo di scrivere. La pulizia per ciascuna di queste dichiarazioni di cattura sarà esattamente la stessa . È un incubo per la manutenzione, per non parlare della leggibilità.

In breve: questo è il problema che RAII è stato creato per risolvere (non che non risolve altri problemi).

Ciò che mi confonde di questa nozione è che è generalmente all'indietro rispetto al modo in cui la maggior parte delle persone sostiene che la RAII è cattiva. In generale, l'argomento dice "RAII è un male perché devi usare le eccezioni per segnalare un errore del costruttore. Ma non puoi lanciare eccezioni, perché non è sicuro e dovrai avere un sacco di catchistruzioni per ripulire tutto". Il che è un argomento rotto perché RAII risolve il problema creato dalla mancanza di RAII.

Molto probabilmente, è contro la RAII perché nasconde i dettagli. Le chiamate ai distruttori non sono immediatamente visibili sulle variabili automatiche. Quindi ottieni codice che viene chiamato in modo implicito. Alcuni programmatori lo odiano davvero. Apparentemente, al punto in cui pensano di avere 3 catchistruzioni, tutte che fanno la stessa cosa con il codice copia e incolla è un'idea migliore.

Due commenti, davvero. Il primo è che mentre sei in un mondo ideale, dovresti sempre sapere quali eccezioni potrebbero essere lanciate, in pratica, se hai a che fare con librerie di terze parti o compilando con un compilatore Microsoft, non lo fai. Più al punto, tuttavia; anche se conosci esattamente tutte le possibili eccezioni, è rilevante qui? catch (...)esprime l'intento molto meglio di catch ( std::exception const& ), anche supponendo che derivino tutte le possibili eccezioni std::exception(che sarebbe il caso in un mondo ideale). Per quanto riguarda l'utilizzo di diversi blocchi di cattura, se non esiste una base comune per tutte le eccezioni: questa è chiaramente offuscamento e un incubo di manutenzione. Come riconosci che tutti i comportamenti sono identici? E quello era l'intento? E cosa succede se devi modificare il comportamento (correzione di bug, ad esempio)? È fin troppo facile perderne uno.

Penso che il tuo collega abbia confuso alcuni buoni consigli: dovresti gestire le eccezioni note in un catchblocco solo quando non le rilasci.

Questo significa:

try
{
  // Stuff
}
catch (...)
{
  // General stuff
}

È male perché nasconderà silenziosamente qualsiasi errore.

Però:

try
{
  // Stuff
}
catch (exception_type_we_can_handle&)
{
  // Deal with the known exception
}

Va bene - sappiamo con cosa abbiamo a che fare e non abbiamo bisogno di esporlo al codice chiamante.

Allo stesso modo:

try
{
  // Stuff
}
catch (...)
{
  // Rollback transactions, log errors, etc
  throw;
}

Va bene, anche la migliore pratica, il codice per gestire gli errori generali dovrebbe essere con il codice che li causa. È meglio che fare affidamento sul chiamato per sapere che una transazione deve essere ripristinata o altro.

Qualsiasi risposta sì o no dovrebbe essere accompagnata da una logica del perché sia ​​così.

Dire che è sbagliato semplicemente perché mi è stato insegnato in quel modo è solo un fanatismo cieco.

Scrivere lo stesso //Some cleanup; throwpiù volte, come nel tuo esempio, è sbagliato perché è la duplicazione del codice e questo è un onere di manutenzione. Scriverlo solo una volta è meglio.

Scrivere a catch(...)per mettere a tacere tutte le eccezioni è sbagliato perché dovresti gestire solo le eccezioni che sai come gestire, e con quel jolly puoi catturare più di quanto ti aspetti, e così facendo puoi mettere a tacere errori importanti.

Ma se ripeti la ricerca dopo un catch(...), allora quest'ultima logica non si applica più, poiché in realtà non stai gestendo l'eccezione, quindi non c'è motivo per cui questo dovrebbe essere scoraggiato.

In realtà l'ho fatto per accedere a funzioni sensibili senza alcun problema:

void DoSomethingImportant()
{
    try
    {
        Log("Going to do something important");
        DoIt();
    }
    catch (std::exception &e)
    {
        Log("Error doing something important: %s", e.what());
        throw;
    }
    catch (...)
    {
        Log("Unexpected error doing something important");
        throw;
    }
    Log("Success doing something important");
}

In genere sono d'accordo con l'umore dei post qui, non mi piace molto il modello di cattura di specifiche eccezioni: penso che la sintassi di questo sia ancora agli inizi e non sia ancora in grado di far fronte al codice ridondante.

Ma dal momento che tutti lo dicono, farò il punto sul fatto che, anche se li uso con parsimonia, ho spesso guardato una delle mie dichiarazioni "catch (Exception e)" e detto "Accidenti, vorrei aver chiamato le eccezioni specifiche di quel tempo "perché quando arrivi più tardi è spesso bello sapere quale fosse l'intenzione e ciò che il cliente potrebbe gettare a colpo d'occhio.

Non sto giustificando l'atteggiamento di "Usa sempre x", sto solo dicendo che occasionalmente è bello vederli elencati e sono sicuro che alcune persone pensano che sia la strada "giusta".