C++ ловя все исключения

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

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

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

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

Только для случая кто-то читает этот поток и думает, что может получить причину катастрофических отказов программы. Отладчик как gdb должен использоваться вместо этого.

Можно использовать

catch(...)

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

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

Примечание, что ... внутренняя часть эти catch является реальным замещающим знаком, т.е. тремя точками.

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

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

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

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

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

А универсальный захватывающий механизм исключения оказался бы чрезвычайно полезным.

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

то, Что Вы действительно хотите, является отладчиком...

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

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

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

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

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

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

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

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

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

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

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

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