C ++ che cattura tutte le eccezioni

Esiste un equivalente c ++ di Java

try {
    ...
}
catch (Throwable t) {
    ...
}

Sto cercando di eseguire il debug del codice Java / jni che chiama le funzioni native di Windows e la macchina virtuale continua a bloccarsi. Il codice nativo appare bene nel test unitario e sembra bloccarsi solo quando viene chiamato tramite jni. Un meccanismo generico di rilevazione delle eccezioni si rivelerebbe estremamente utile.

try{
    // ...
} catch (...) {
    // ...
}

catturerà tutte le eccezioni C ++, ma dovrebbe essere considerato un design errato. Puoi usare il nuovo meccanismo current_exception di c ++ 11, ma se non hai la possibilità di usare c ++ 11 (sistemi di codice legacy che richiedono una riscrittura), allora non hai un puntatore d'eccezione con nome da usare per ottenere un messaggio o un nome . Potresti voler aggiungere clausole di cattura separate per le varie eccezioni che puoi rilevare e prendere tutto ciò che è in basso per registrare un'eccezione imprevista. Per esempio:

try{
    // ...
} catch (const std::exception& ex) {
    // ...
} catch (const std::string& ex) {
    // ...
} catch (...) {
    // ...
}

Qualcuno dovrebbe aggiungere che non si possono intercettare "arresti anomali" nel codice C ++. Quelli non generano eccezioni, ma fanno tutto ciò che vogliono. Quando vedi un programma che si arresta in modo anomalo a causa di una dereferenza con puntatore null, sta facendo un comportamento indefinito. Non c'è std::null_pointer_exception. Cercare di catturare le eccezioni non ci aiuterà.

Solo per il caso qualcuno sta leggendo questo thread e pensa di poter ottenere la causa degli arresti anomali del programma. Invece dovrebbe essere usato un debugger come gdb.

Ecco come è possibile decodificare il tipo di eccezione dall'interno catch(...)se necessario (può essere utile quando si rileva l'ignoto da una libreria di terze parti) con GCC:

#include <iostream>

#include <exception>
#include <typeinfo>
#include <stdexcept>

int main()
{
    try {
        throw ...; // throw something
    }
    catch(...)
    {
        std::exception_ptr p = std::current_exception();
        std::clog <<(p ? p.__cxa_exception_type()->name() : "null") << std::endl;
    }
    return 1;
}

e se puoi permetterti di usare Boost puoi rendere la tua sezione di cattura ancora più semplice (all'esterno) e potenzialmente multipiattaforma

catch (...)
{
    std::clog << boost::current_exception_diagnostic_information() << std::endl;
}

try {
   // ...
} catch (...) {
   // ...
}

Si noti che ...all'interno delcatch è una vera ellissi, cioè. tre punti.

Tuttavia, poiché le eccezioni C ++ non sono necessariamente sottoclassi di una Exceptionclasse base , non è possibile vedere effettivamente la variabile di eccezione generata quando si utilizza questo costrutto.

non è possibile (in C ++) catturare tutte le eccezioni in modo portatile. Questo perché alcune eccezioni non sono eccezioni in un contesto C ++. Ciò include cose come la divisione per zero errori e altri. È possibile hackerare e quindi ottenere la possibilità di generare eccezioni quando si verificano questi errori, ma non è facile da fare e certamente non è facile da ottenere in modo portatile.

Se vuoi catturare tutte le eccezioni STL, puoi farlo

try { ... } catch( const std::exception &e) { ... }

Che ti permetterà di usare e.what(), che restituirà a const char*, che può dirti di più sull'eccezione stessa. Questo è il costrutto che ricorda di più il costrutto Java, di cui hai chiesto.

Questo non ti aiuterà se qualcuno è abbastanza stupido da lanciare un'eccezione che non eredita std::exception.

In breve, usare catch(...). Tuttavia, si noti che catch(...)è pensato per essere utilizzato in combinazione con throw;sostanzialmente:

try{
    foo = new Foo;
    bar = new Bar;
}
catch(...)       // will catch all possible errors thrown. 
{ 
    delete foo;
    delete bar;
    throw;       // throw the same error again to be handled somewhere else
}

Questo è il modo corretto di usare catch(...).

è possibile farlo scrivendo:

try
{
  //.......
}
catch(...) // <<- catch all
{
  //.......
}

Ma qui c'è un rischio molto evidente: non riesci a trovare il tipo esatto di errore che è stato generato nel tryblocco, quindi usa questo tipo di catchquando sei sicuro che, indipendentemente dal tipo di eccezione, il programma deve persistere nel modo definito nel catchblocco.

Puoi usare

catch(...)

ma è molto pericoloso. Nel suo libro Debugging di Windows , John Robbins racconta una storia di guerra su un bug davvero brutto che è stato mascherato da un comando catch (...). Farai molto meglio a cogliere eccezioni specifiche. Prendi qualunque cosa pensi che il tuo blocco try possa ragionevolmente lanciare, ma lascia che il codice generi un'eccezione più in alto se succede qualcosa di veramente imprevisto.

Consentitemi di menzionarlo qui: Java

try 
{
...
}
catch (Exception e)
{
...
}

potrebbe NON cogliere tutte le eccezioni! In realtà ho avuto questo genere di cose prima, ed è provocatorio; L'eccezione deriva da Throwable. Quindi, letteralmente, per catturare tutto, NON vuoi catturare Eccezioni; vuoi prendere Throwable.

So che suona nitido, ma quando hai passato diversi giorni a cercare di capire da dove provenisse l '"eccezione non rilevata" nel codice che era circondato da un blocco try ... catch (Exception e) ", si attacca con tu.

Bene, se vuoi prendere tutte le eccezioni per creare un minidump per esempio ...

Qualcuno ha fatto il lavoro su Windows.

Vedi http://www.codeproject.com/Articles/207464/Exception-Handling-in-Visual-Cplusplus Nell'articolo, spiega come ha scoperto come catturare tutti i tipi di eccezioni e fornisce il codice che funziona.

Ecco l'elenco che puoi prendere:

 SEH exception
 terminate
 unexpected
 pure virtual method call
 invalid parameter
 new operator fault 
 SIGABR
 SIGFPE
 SIGILL
 SIGINT
 SIGSEGV
 SIGTERM
 Raised exception
C++ typed exception

E l'uso: CCrashHandler ch; ch.SetProcessExceptionHandlers (); // fallo per un thread ch.SetThreadExceptionHandlers (); // per ogni thred

Per impostazione predefinita, questo crea un minidump nella directory corrente (crashdump.dmp)

Un meccanismo generico di rilevazione delle eccezioni si rivelerebbe estremamente utile.

Dubbioso. Sai già che il tuo codice è rotto, perché si sta bloccando. Le eccezioni alimentari possono mascherare questo, ma probabilmente si tradurrà in bug ancora più cattivi e sottili.

Quello che vuoi davvero è un debugger ...

1. È possibile eseguire l'applicazione Java utilizzando JNI da una finestra della console (avviarla da una riga di comando java) per vedere se esiste un rapporto su ciò che potrebbe essere stato rilevato prima che la JVM si arrestasse in modo anomalo. Quando si esegue direttamente come un'applicazione per finestre Java, è possibile che manchino messaggi che potrebbero apparire se si eseguisse invece da una finestra della console.

2. In secondo luogo, puoi stub dell'implementazione della DLL JNI per mostrare che i metodi nella tua DLL vengono immessi da JNI, stai tornando correttamente, ecc.?

3. Nel caso in cui il problema riguardi un uso errato di uno dei metodi dell'interfaccia JNI dal codice C ++, hai verificato che alcuni semplici esempi JNI compilano e funzionano con la tua configurazione? Sto pensando in particolare all'utilizzo dei metodi dell'interfaccia JNI per convertire i parametri in formati C ++ nativi e trasformare i risultati delle funzioni in tipi Java. È utile stubare quelli per assicurarsi che le conversioni di dati funzionino e che non si vada in tilt nelle chiamate simili a COM nell'interfaccia JNI.

4. Ci sono altre cose da controllare, ma è difficile suggerire qualsiasi senza sapere di più su quali siano i tuoi metodi Java nativi e cosa sta cercando di fare l'implementazione JNI di essi. Non è chiaro che la cattura di un'eccezione dal livello di codice C ++ sia correlata al tuo problema. (È possibile utilizzare l'interfaccia JNI per riproporre l'eccezione come Java, ma non è chiaro da cosa fornite che ciò possa aiutare.)

Per il vero problema di non riuscire a eseguire correttamente il debug di un programma che utilizza JNI (o il bug non appare quando lo si esegue con un debugger):

In questo caso spesso aiuta ad aggiungere wrapper Java attorno alle chiamate JNI (ovvero tutti i metodi nativi sono privati ​​e i metodi pubblici nella classe li chiamano) che eseguono alcuni controlli di integrità di base (controlla che tutti gli "oggetti" siano liberati e "oggetti" non vengono utilizzati dopo la liberazione) o la sincronizzazione (basta sincronizzare tutti i metodi da una DLL a una singola istanza di oggetto). Lascia che i metodi del wrapper Java registrino l'errore e generino un'eccezione.

Ciò contribuirà spesso a trovare il vero errore (che sorprendentemente si trova principalmente nel codice Java che non obbedisce alla semantica delle funzioni chiamate causando alcune brutte doppie liberazioni o simili) più facilmente rispetto al tentativo di eseguire il debug di un programma Java massicciamente parallelo in un debugger nativo ...

Se conosci la causa, mantieni il codice nei metodi wrapper che lo evita. È meglio che i tuoi metodi wrapper generino eccezioni rispetto al tuo codice JNI in crash la VM ...

Bene, questo dipende davvero dall'ambiente del compilatore. gcc non li cattura. Visual Studio e l'ultimo Borland che ho usato hanno fatto.

Quindi la conclusione sugli arresti anomali è che dipende dalla qualità dell'ambiente di sviluppo.

La specifica C ++ afferma che catch (...) deve catturare eventuali eccezioni, ma non in tutti i casi.

Almeno da quello che ho provato.

Sii consapevole

try{
// ...
} catch (...) {
// ...
}

rileva solo le eccezioni a livello di lingua, altre eccezioni / errori di basso livello come Access Violatione Segmentation Faultnon verranno rilevate.