![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
- c++,
- concurrency,
- freesoftware,
- gcc,
- library,
- linux,
- ms windows,
- plain c,
- posix
Вопрос: Как дела с catch(...) в MS?
Думаю, многие из вас в курсе, что в NPTL механизм pthread_cancel() реализован с помощью исключений. Таким образом, следует избегать нейтрализации catch(...).
Знающие люди, а скажите, есть ли в мелко-мягкой среде какие-то подводные камни, из-за которых тоже следует избегать такой нейтрализации?
Заранее благодарен! :-)
Update: Обратные ссылки: alextutubalin: Об исключениях (C++)
Знающие люди, а скажите, есть ли в мелко-мягкой среде какие-то подводные камни, из-за которых тоже следует избегать такой нейтрализации?
Заранее благодарен! :-)
Update: Обратные ссылки: alextutubalin: Об исключениях (C++)
no subject
Re: Нету
no subject
Re: Я бы на всякий случай взглянул бы в SEH. Для очистки со
Но если таки очистишь совесть - дай знать! ;-)
Re: Я бы на всякий случай взглянул бы в SEH. Для очистки со
API c-шный, потому никаких try/catch, как можно догадаться.
В чём мегабяка такого шатдауна — если тред держит какойнить критикл_секшн (может и не сам, может где в кишках сторонней билибитеки или самого вантуза). Ну и ваще шатдаунить надо корректно.
Re: Я бы на всякий случай взглянул бы в SEH. Для очистки со
Мне нужно обеспечить недопустимость вырывания наружу исключений за plain-C интерфейс. Из поста следует, что не все исключения я должен гасить, но это - в среде Линукса.
Re: Я бы на всякий случай взглянул бы в SEH. Для очистки со
1) В твою библиотеку передаётся callback
2) Библиотека вызывает callback
3) callback кидает исключение
Тут надо определиться, может ли callback кидать исключение. Вроде как у либы интерфейс plain C, так что никаких С++ исключений быть не должно. Но могут попробовать кинуть исключение SEH и скорее всего catch(...) его поймает.
Короче в любом случае надо определяться, могут ли callback'и кидать исключения, т. к. в этом случае в дизайне либы это должно учитываться.
Re: Я бы на всякий случай взглянул бы в SEH. Для очистки со
Я и сам понял это.
Обязательно добавлю комментарий в заголовочный файл plain-C интерфейса, что же ожидается от передаваемого обратного вызова и что лучше будет использовать лежащий в основе C++ интерфейс библиотеки.
Re: Я бы на всякий случай взглянул бы в SEH. Для очистки со
Re: Я бы на всякий случай взглянул бы в SEH. Для очистки со
(Anonymous) 2011-08-28 04:31 pm (UTC)(link)Это приводит к очень неприятным последствиям - в частности, catch(...) у MS перехватывает даже GPF (AKA segmentation fault), что вряд ли ожидает, гм, удивлённый и огорчённый программист.
no subject
или хотя бы гнать ссаными тряпками :)
потому что если где-то что-то сегфолтится и нейтрализуется этим кэтчем, то узнаешь ты об этом как правило слишком поздно
Re: за catch( ... ) без rethrow вообще надо убивать
Что сделаешь, если у тебя реализация на Си++, а тебя просят спрятать это за обычным Си, требуя, чтобы никаких исключений не вырывалось наружу?
Да, есть некоторый набор исключений самой библиотеки.
Но она использует, например, STL.
no subject
делаешь catch( std::exception& e ) и все
можешь даже после этого в сишный интерфейс какую-нибудь строковую ошибку вернуть (по e.what() выдастся const char *
Re: в чем проблема? все исключения STL унаследованы от std::e
Спасибо!
no subject
Re: сделай проверку, e.what() вполне может вернуть NULL
А тип исключения, действительно, может многое сказать, ведь базовый класс STL исключений содержит виртуальную таблицу, а значит, можно получить run-time type infromation - люблю этим пользоваться в этих случаях.
Re: сделай проверку, e.what() вполне может вернуть NULL
Re: сделай проверку, e.what() вполне может вернуть NULL
"А вы так - не делайте!"
Re: сделай проверку, e.what() вполне может вернуть NULL
Re: сделай проверку, e.what() вполне может вернуть NULL
У меня вызовы - кошерные? Кошерные!
Библиотека с остальным кодом в исполняемый модуль собралась? Собралась!
Что ты ещё от меня хочешь?
А прострелить себе ногу - я тебе могу и без исключений и в одной среде способов предложить; те же встроенные конструкторы и невстроенные деструкторы: создавай одни в одной библиотеке в отладке, а разрушай - в другой в релизе, ну или что-то в этом роде.
Re: сделай проверку, e.what() вполне может вернуть NULL
Re: сделай проверку, e.what() вполне может вернуть NULL
Да, мне и без этих мыслей - хватает, чем задуматься.
Но ты, эта, держи меня в тонусе, продолжай писать... ;-)
no subject
Re: Идея с catch(std::exception &), кстати, подходит.
Всем спасибо!
Я должен был бы сам догадаться и не тревожить общественность по пустякам...
no subject
конструкторы вообще не должны ничего кидать, это когда-то было debatable, но в итоге порешали что ну его нафиг, но это к вопросу мало относится
Re: конструкторы вообще не должны ничего кидать, это ког
Деструкторы - да, согласен, не должны.
no subject
конструкторы могут, деструкторы не могут
no subject
Re: а я даже не понял вопроса:) но,уверен, что в конце конц
Как сам-то?
Доволен работой в результате?
Re: а я даже не понял вопроса:) но,уверен, что в конце конц
Сорри что не сразу ответил, твой комментарий потерялся)
Re: а я даже не понял вопроса:) но,уверен, что в конце конц
И не стоит волноваться, я вполне понимаю...
А на ЖЖ - я и сам забиваю...
Хотя, конечно, на активность - отвечаю активностью!
(в смысле, если уж комментарии есть - как минимум просматриваю)