C ++, що охоплює всі винятки

Чи є еквівалент c ++ Java

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

Я намагаюся налагодити код Java / jni, який викликає нативні функції Windows, і віртуальна машина продовжує збої. Нативний код здається відмінним при тестуванні одиниць і, здається, руйнується лише при виклику через jni. Загальний механізм вилучення винятків виявиться надзвичайно корисним.

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

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

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

Хтось повинен додати, що в C ++-коді неможливо зловити "збої". Вони не кидають винятків, але роблять все, що їм подобається. Коли ви бачите програму, яка виходить з ладу через скажімо затримку з нульовим вказівником, вона робить не визначене поведінку. Немаєstd::null_pointer_exception . Спроба зловити винятки не допоможе.

Просто на випадок, коли хтось читає цю тему і думає, що може отримати причину збоїв у програмі. Замість цього слід використовувати налагоджувач, як gdb.

Ось як ви можете змінити інженерний тип винятку зсередини, 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;
}

і якщо ви можете дозволити собі використання Boost, ви можете зробити свою секцію вилову ще простішою (зовні) та потенційно кросплатформою

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

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

Зауважимо, що ...всерединіcatch є справжній еліпсис, тобто. три крапки.

Однак, оскільки винятки C ++ не обов'язково є підкласами базового Exceptionкласу, не існує жодного способу побачити змінну винятків, яка викидається при використанні цієї конструкції.

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

Якщо ви хочете знайти всі винятки STL, ви можете зробити це

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

Що дозволить вам використовувати e.what(), що поверне a const char*, що може розповісти більше про сам виняток. Це та конструкція, яка найбільше нагадує конструкцію Java, про яку ви питали найбільше.

Це вам не допоможе, якщо хтось досить дурний, щоб кинути виняток, від якого не успадковується std::exception.

Словом, використовуйте 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(...).

це можна зробити, написавши:

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

Але тут є дуже непомітний ризик: ви не можете знайти точний тип помилки, який був кинутий у tryблок, тому використовуйте цей тип, catchколи ви впевнені, що незалежно від типу винятку, програма повинна зберігатися способом, визначеним у catchблоці.

Можна використовувати

catch(...)

але це дуже небезпечно. У своїй книзі « Налагодження Windows» Джон Роббінс розповідає військову історію про справді неприємну помилку, яку замаскували командою catch (...). Вам набагато краще ловити конкретні винятки. Ловіть все, що ви думаєте, ваш спробувальний блок може розумно кинути, але нехай код кидає виняток вище, якщо трапиться щось дійсно несподіване.

Дозвольте тут згадати лише таке: Java

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

НЕ МОЖЕ вловлювати всі винятки! У мене насправді раніше таке траплялося, і це викликає ненаситність; Виняток походить від Throwable. Так буквально, щоб зловити все, ви НЕ хочете зловити Винятки; ви хочете зловити Throwable.

Я знаю, що це звучить нерозумно, але коли ви витратили кілька днів, намагаючись з'ясувати, звідки взявся "неприхований виняток" у коді, який був оточений блоком "спробувати ... ти.

Ну, якщо ви хочете зловити всі винятки, щоб створити мінімум, наприклад ...

Хтось робив роботу в 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)

Загальний механізм вилучення винятків виявиться надзвичайно корисним.

Сумнівні. Ви вже знаєте, що ваш код зламаний, оскільки він виходить з ладу. Їх винятки можуть замаскувати це, але це, ймовірно, призведе до ще більш гнучких, тонких помилок.

Те, що ти насправді хочеш - це налагоджувач ...

1. Чи можете ви запустити додаток Java, що використовує JNI, у вікні консолі (запустіть його з командного рядка java), щоб побачити, чи є звіт про те, що можливо було виявлено до того, як JVM був розбитий. Під час запуску безпосередньо як віконної програми Java, у вас можуть бути відсутні повідомлення, які з’являться, якщо ви замість цього запустите з вікна консолі.

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

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

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

Для реальної проблеми щодо неможливості належної налагодження програми, яка використовує JNI (або помилка не з’являється під час її запуску під налагоджувачем):

У цьому випадку часто допомагає додавати обгортки Java навколо ваших дзвінків JNI (тобто всі нативні методи приватні, а ваші загальнодоступні методи в класі називають їх), які роблять основні перевірки правильності (перевірте, чи звільнені всі "об'єкти" та "об'єкти" не використовуються після звільнення) або синхронізації (просто синхронізуйте всі методи з однієї DLL в один екземпляр об'єкта). Нехай методи обгортки java фіксують помилку та викидають виняток.

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

Якщо ви знаєте причину, зберігайте код у своїх обгорткових методах, які уникнуть його. Краще, щоб ваші способи обгортки кидали винятки, ніж ваш код JNI аваріїв ВМ ...

Ну, це дійсно залежить від середовища компілятора. gcc не вловлює цих. Visual Studio і останній Borland, який я використовував.

Отже, висновок про збої полягає в тому, що це залежить від якості вашого середовища розробки.

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

Принаймні з того, що я спробував.

Бережись

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

фіксує лише винятки на мовному рівні, інші винятки / помилки низького рівня, такі як Access Violationі Segmentation Faultне можуть бути схоплені.