C++ перехватывает все исключения

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

Обратите внимание, что ... внутри catch - это настоящее многоточие, т.е. три точки.

Однако, поскольку исключения C++ не обязательно являются подклассами базового класса Exception, нет никакого способа фактически увидеть переменную исключения, которая создается при использовании этой конструкции.

Вы можете использовать

catch(...)

но это очень опасно. В своей книге Отладка Windows Джон Роббинс рассказывает военную историю об очень неприятной ошибке, замаскированной с помощью команды catch (...). Намного лучше ловить определенные исключения. Поймайте все, что, по вашему мнению, может вызвать ваш блок try, но позвольте коду генерировать исключение выше, если произойдет что-то действительно неожиданное.

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

перехватит все исключения C++, но это следует считать плохим дизайном. Вы можете использовать новый механизм C++ 11 current_exception, но если у вас нет возможности использовать C++ 11 (устаревшие кодовые системы, требующие перезаписи), то у вас нет указателя на именованное исключение, которое можно было бы использовать для получения сообщения или имени. . Вы можете добавить отдельные предложения catch для различных исключений, которые вы можете перехватить, и перехватить только все, что находится внизу, для записи неожиданного исключения. Например.:

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

Позвольте мне просто упомянуть здесь: Java

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

НЕ может ловить все исключения! У меня действительно случалось подобное раньше, и это безумно провоцирует; Исключение происходит от Throwable. Итак, буквально, чтобы поймать все, вы НЕ хотите ловить исключения; вы хотите поймать Throwable.

Я знаю, это звучит придирчиво, но когда вы потратили несколько дней, пытаясь выяснить, откуда взялось "неперехваченное исключение" в коде, который был окружен блоком try ... catch (Exception e) ", он застрял с ты.

A generic exception catching mechanism would prove extremely useful.

Сомнительно. Вы уже знаете, что ваш код сломан, потому что он дает сбой. Использование исключений может замаскировать это, но это, вероятно, приведет к еще более неприятным, более тонким ошибкам.

Что вам действительно нужно, так это отладчик ...

Кому-то стоит добавить, что в C++ коде нельзя отловить "сбои". Они не создают исключений, но делают все, что им нравится. Когда вы видите, что программа вылетает из-за, скажем, разыменования нулевого указателя, она ведет себя неопределенно. std::null_pointer_exception нет. Попытка поймать исключения здесь не поможет.

На всякий случай кто-то читает эту ветку и думает, что может выяснить причину сбоя программы. Вместо этого следует использовать отладчик, такой как gdb.

1. Можете ли вы запустить приложение Java с использованием JNI из окна консоли (запустить его из командной строки java), чтобы увидеть, есть ли какой-либо отчет о том, что могло быть обнаружено до того, как JVM разбился. При запуске непосредственно в качестве оконного приложения Java у вас могут отсутствовать сообщения, которые могли бы появиться, если бы вы запускали вместо этого из окна консоли.

2. Во-вторых, можете ли вы заглушить свою реализацию JNI DLL, чтобы показать, что методы в вашей DLL вводятся из JNI, вы возвращаетесь правильно и т. д.?

3. На всякий случай, если проблема связана с неправильным использованием одного из методов JNI-интерфейса из кода C++, проверили ли вы, что некоторые простые примеры JNI компилируются и работают с вашей настройкой? Я думаю, в частности, об использовании методов JNI-интерфейса для преобразования параметров в собственные форматы C++ и преобразования результатов функций в типы Java. Полезно заглушить их, чтобы убедиться, что преобразования данных работают, и вы не сбиваетесь с пути в COM-подобных вызовах в интерфейс JNI.

4. Есть и другие вещи, которые нужно проверить, но трудно предложить что-либо, не зная больше о ваших собственных методах Java и о том, что их реализация JNI пытается сделать. Неясно, связано ли обнаружение исключения на уровне кода C++ с вашей проблемой. (Вы можете использовать интерфейс JNI, чтобы повторно выбросить исключение как Java, но из того, что вы предоставляете, не ясно, что это поможет.)

невозможно (в C++) перехватить все исключения переносимым способом. Это связано с тем, что некоторые исключения не являются исключениями в контексте C++. Сюда входят такие вещи, как деление на ноль ошибок и другие. Можно взломать и, таким образом, получить возможность генерировать исключения при возникновении этих ошибок, но это нелегко сделать и, конечно, нелегко исправить в переносном режиме.

Если вы хотите перехватить все исключения STL, вы можете сделать

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

Это позволит вам использовать e.what(), который вернет const char*, который может рассказать вам больше о самом исключении. Эта конструкция больше всего напоминает конструкцию Java, о которой вы спрашивали.

Это не поможет вам, если кто-то достаточно глуп, чтобы выбросить исключение, которое не наследуется от std::exception.

Что касается реальной проблемы невозможности правильно отладить программу, использующую JNI (или ошибка не появляется при ее запуске под отладчиком):

В этом случае часто помогает добавить Java-оболочки вокруг ваших вызовов JNI (т.е. все собственные методы являются частными, а ваши общедоступные методы в классе вызывают их), которые выполняют некоторую базовую проверку работоспособности (убедитесь, что все «объекты» освобождены, а «объекты» не используются после освобождения) или синхронизации (просто синхронизируйте все методы из одной DLL с одним экземпляром объекта). Позвольте методам оболочки java записывать ошибку и генерировать исключение.

Это часто помогает найти настоящую ошибку (которая, как ни странно, в основном находится в коде Java, который не подчиняется семантике вызываемых функций, вызывая некоторые неприятные двойные освобождения или что-то подобное) легче, чем попытки отладить массово параллельную программу Java в родной отладчик ...

Если вы знаете причину, сохраните код в методах-оболочках, которые ее избегают. Лучше пусть ваши методы-оболочки генерируют исключения, чем ваш код JNI приводит к сбою виртуальной машины ...

это можно сделать, написав:

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

Но здесь есть очень незаметный риск: вы не можете найти точный тип ошибки, которая была выдана в блоке try, поэтому используйте этот тип catch, когда вы уверены, что независимо от типа исключения, программа должен сохраняться способом, определенным в блоке catch.

Короче используйте catch(...). Однако обратите внимание, что catch(...) предназначен для использования в основном вместе с throw;:

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
}

Это правильный способ использования catch(...).

Вот как вы можете реконструировать тип исключения из catch(...), если вам это нужно (может быть полезно при отлове неизвестного из сторонней библиотеки) с помощью 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;
}

и если вы можете позволить себе использовать Способствовать росту, вы можете сделать раздел улова еще проще (снаружи) и потенциально кроссплатформенным.

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

Что ж, если вы хотите перехватить все исключения, например, для создания минидампа ...

Кто-то проделал работу в Windows.

См. http://www.codeproject.com/Articles/207464/Exception-Handling-in-Visual-Cplusplus В статье он объясняет, как он узнал, как перехватывать все виды исключений, и предоставляет работающий код.

Вот список, который вы можете поймать:

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

И использование: CCrashHandler ch; ch.SetProcessExceptionHandlers (); // делаем это для одного потока ch.SetThreadExceptionHandlers (); // для каждого потока

По умолчанию это создает минидамп в текущем каталоге (crashdump.dmp).

Ну, это действительно зависит от среды компилятора. gcc их не улавливает. Visual Studio и последний Borland, который я использовал, сделали.

Итак, вывод о сбоях заключается в том, что это зависит от качества вашей среды разработки.

C++ Спецификация говорит, что catch (...) должен перехватывать любые исключения, но не во всех случаях.

По крайней мере, из того, что я пробовал.

Быть в курсе

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

перехватывает только исключения уровня языка, другие исключения / ошибки низкого уровня, такие как Access Violation и Segmentation Fault, не будут обнаружены.