Co się stanie, jeśli użyję "rzutu"; bez wyjątku do rzutu?

Question

Oto konfiguracja.

Mam C++ program, który wywołuje kilka funkcji, z których wszystkie potencjalnie rzucić ten sam zestaw wyjątku, a ja chcę to samo zachowanie dla wyjątków w każdej funkcji (np drukowania komunikat o błędzie & przywrócić wszystkie dane do domyślnego dla wyjątkuA; po prostu wydrukuj dla wyjątkuB; zamknij całkowicie dla wszystkich innych wyjątków).

Wydaje się, że powinienem być w stanie ustawić zachowanie catch zadzwonić prywatną funkcję, która po prostu ponownie generuje błąd i wykonuje połowy, tak jak poniżej:

void aFunction() 
{ 
    try{ /* do some stuff that might throw */ } 
    catch(...){handle();} 
} 

void bFunction() 
{ 
    try{ /* do some stuff that might throw */ } 
    catch(...){handle();} 
} 

void handle() 
{ 
    try{throw;} 
    catch(anException) 
    { 
     // common code for both aFunction and bFunction 
     // involving the exception they threw 
    } 
    catch(anotherException) 
    { 
     // common code for both aFunction and bFunction 
     // involving the exception they threw 
    } 
    catch(...) 
    { 
     // common code for both aFunction and bFunction 
     // involving the exception they threw 
    } 
} 

Teraz, co się stanie, jeśli „obsłużyć” jest wywoływany poza klasą wyjątków. Jestem świadomy, że to nigdy nie powinno się zdarzyć, ale zastanawiam się, czy zachowanie jest niezdefiniowane przez standard C++.

Answer 1

Jeśli zostanie wywołane handle() poza kontekstem wyjątku, będzie można uzyskać throw bez obsługi wyjątku. W tym przypadku średnia (patrz punkt 15.5.1) określa, że ​​

Jeśli żaden wyjątek jest obecnie obsługiwane, wykonując throw-expression z połączeń nie operand terminate().

, więc Twój wniosek zostanie rozwiązany. To chyba nie jest to, czego chcesz tutaj.

Answer 2

Jeśli użyjesz throw wewnątrz bloku catch, to wyrzuci wyjątek. Jeśli użyjesz rzut poza blokiem catch, to zakończy aplikację.

Answer 3

Nigdy, nigdy, nigdy, nigdy nie używaj catch (...), ponieważ możesz złapać błędy aplikacji, których nie chcesz przechwytywać, np. błędy, naruszenia zasad dostępu (w zależności od sposobu kompilacji).

Przeczytaj wielką książkę Johna Robbinsa (Debugowanie aplikacji systemu Windows), w której wyjaśnia bardziej szczegółowo, dlaczego nie powinieneś tego robić.