Вопрос: Как дела с catch(...) в MS?

[dememax]

Думаю, многие из вас в курсе, что в NPTL механизм pthread_cancel() реализован с помощью исключений. Таким образом, следует избегать нейтрализации catch(...).

Знающие люди, а скажите, есть ли в мелко-мягкой среде какие-то подводные камни, из-за которых тоже следует избегать такой нейтрализации?

Заранее благодарен! :-)

Update: Обратные ссылки: alextutubalin: Об исключениях (C++)

Comments

Re: Я бы на всякий случай взглянул бы в SEH. Для очистки со

[esil0x.livejournal.com]

Есть один случай, который таки может сломаться. Это когда:

1) В твою библиотеку передаётся callback
2) Библиотека вызывает callback
3) callback кидает исключение

Тут надо определиться, может ли callback кидать исключение. Вроде как у либы интерфейс plain C, так что никаких С++ исключений быть не должно. Но могут попробовать кинуть исключение SEH и скорее всего catch(...) его поймает.

Короче в любом случае надо определяться, могут ли callback'и кидать исключения, т. к. в этом случае в дизайне либы это должно учитываться.

Re: Я бы на всякий случай взглянул бы в SEH. Для очистки со

[dememax]

Да, спасибо за напоминание и развёрнутое объяснение!

Я и сам понял это.
Обязательно добавлю комментарий в заголовочный файл plain-C интерфейса, что же ожидается от передаваемого обратного вызова и что лучше будет использовать лежащий в основе C++ интерфейс библиотеки.

Re: Я бы на всякий случай взглянул бы в SEH. Для очистки со

[rezdm.livejournal.com]

Меня терают смутные сомнения, что кетч-три-точки словит СЕХ. Также, как и обратно.

Re: Я бы на всякий случай взглянул бы в SEH. Для очистки со

[(Anonymous)]

Не "скорее всего поймает", а "точно поймает". MS реализует исключения C++ на механизме SEH, поэтому, например, любое асинхронное исключение, вроде floating-point exception, выглядит для C++ как throw int(номер-исключения). Если кто забыл, throw можно значение любого типа - это нам не Ява.
Это приводит к очень неприятным последствиям - в частности, catch(...) у MS перехватывает даже GPF (AKA segmentation fault), что вряд ли ожидает, гм, удивлённый и огорчённый программист.