MFC? Конечно, можно полагать, что все исключения унаследованы от std::exception, но всё равно полезно иметь catch(...) обработчик на самом высоком уровне, если не хочешь, чтобы твоя программа просто падала, когда выбросится что либо неожиданное.

все ли строки в C++ это std::string?

SUBJ

Всё зависит от упоротости текущего разработчика. Если даже сейчас в сферическом проекте таких исключений нет, то никто не гарантирует, что их не будет в будущем.

хоть char*

Вот тут есть поле для дискуссии. throw может вызвать copy ctor. Что для указателя ты вызывать будешь?

По теме, в ACE свои исключения, и даже свои макросы для THROW CATCH.

По теме, в ACE свои исключения, и даже свои макросы для THROW CATCH.

Да? И где же они определены?

Уже не помню, как оно было в MFC и было ли вообще. А вот среди того, с чем доводилось сталкиваться в последние лет десять, вспоминается разве что OTL. Тамошний класс otl_exception по умолчанию ни от чего не наследуется. Но можно использовать макросы OTL_EXCEPTION_DERIVED_FROM+OTL_EXCEPTION_HAS_MEMBERS или OTL_EXCEPTION_IS_DERIVED_FROM_STD_EXCEPTION чтобы сделать otl_exception наследником std::exception (или любого другого определенного в STL класса исключений).

обработчик на самом высоком уровне, если не хочешь, чтобы твоя программа просто падала, когда выбросится что либо неожиданное.

А остаться в неопределенном состоянии из-за подавленного исключения - типа ок? Такое отловленное исключение вообще ничего не скажет о том, откуда оно и почему. IMHO в таких случаях как раз лучше падать с дампом и потом разбираться.

И остаться не неосвобожденными ресурсами.

If no matching handler is found in a program, the function terminate()

(_except.terminate_) is called. Whether or not the stack is unwound before calling terminate() is implementation-defined.

Не согласен. Кейс:

Твоё api - дергает пользовательский коллбэк.

Что лучше - упасть, или таки сказать пользователю ай яй яй?

Что лучше - упасть, или таки сказать пользователю ай яй яй?

А что вообще можно сказать пользовалелю на исключение неизвестного типа? И что программа должна пытаться делать дальше? Логично свернуть стек и закрыться. Так стандартное поведение необработанного исключения делает то же самое. Плюс в нормальных ОС диалог пользователю показывается.

Это, если пользователь - один.

Иначе, максимум, что ты в праве сделать - отключить этого пользователя.

windows рулит!

Наследоваться от std::exception это даже не правило хорошего тона. Хотя бы потому что задекларированные исключения в функциях всё равно должны быть обработаны специальными блоками, а не неким абстрактным catch (const std::exception &), который максимум может ошибку в лог записать, а что делать дальше ему неведомо. Наследоваться от std::exception (и его производных) можно чтобы не городить огород, когда тебя устраивает уже готовая семантика разделения исключений на logic_error, runtime_error и прочие готовые к использованию классы.

Походу в новых версиях убрали: в TAO/NEWS пишут, что в 1.5.6 и 1.5.7 все макросы выпилили.

Но таки классы свои есть, например:

TAO/tao/Exception.h

LuaJIT, будучи по дефолту собранным с dwarf2, кидает char* (ванильный Lua хз, там sjlj из-за анси). Другие эксцепшены он ловит и презентует как «c++ exception». Объектив-Си эксцепшены это NSException, в последнее время допустимо кидать id, чаще всего NSString. В общем-то исключения это не исключительно крестовое изобретение и/или механизм, и в гетерогенной среде ты будешь ловить что угодно, кроме этого вашего std::exception.

Походу в новых версиях убрали: в TAO/NEWS пишут, что в 1.5.6 и 1.5.7 все макросы выпилили.

Не надо путать ACE и TAO.

ACE — это базовая библиотека, позволяющая абстрагироваться от системно-зависимого уровня.

TAO — это реализация CORBA, в которой используется ACE в качестве базового слоя.

И за ACE, и за TAO стоят одни и те же люди, но это разные программные продукты. А исключения в TAO есть потому, что они определены в самой CORBA. Ну, насколько я помню, первый стандарт отображения CORBA-to-C++ был выпущен еще до выхода стандарта C++98. Сейчас есть CORBA-to-C++11, которая реализуется TAOX11. Там, AFAIK, исключения уже наследуются от std::exception.

Знаете ли вы real-world проекты, где выбрасываются исключения, не порожденные от std::exception?

Glib::Exception

да, но это просто гномий в*ебон, который отличается только тем, что ипользует glib::ustring с тем же char* вместо std::basic_string<char>

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

Мне кажется если одно из условий работы сервиса стабильная работа

Какие могут быть гарантии стабильной работы после левого исключения? Уж лучше упасть и перезапуститься и потом действительно стабильно работать.

И остаться не неосвобожденными ресурсами.

Это какие еще такие неосвобожденные ресурсы? ОС подметет и память, и дескрипторы.

Твоё api - дергает пользовательский коллбэк.

Что лучше - упасть, или таки сказать пользователю ай яй яй?

1. Так пользовательский или программистский?

2. Вызов 3-rd party code всегда обязан быть обрамлен в catch(...) (кроме отладочного режима/сборки для этих самых 3-rd party).

Несброшенные кеши, неудаленные временные файлы или таблички, например. Да мало ли что.

Чем программист - не пользователь/клиент?

Программисту не надо красивых сообщений - он и по дампу все поймет и простит.

Ну смотря что надо. На вот например лезть к каждой желеке лень было вот мы и сделали отправку тупого error при левом запросе с выводом ога в каком месте словили ошибку.

Ага :)

Но с красивым иной раз жить проще.

в последних версиях они их убрали.

Но с красивым иной раз жить проще.

Красивым, но без дампа? Не-не-не, спасибо. Я такого уже наелся на практике. Когда на критический баг есть только лог «unhandled exception in the main thread» и все, что можно - сказать «Сори, только если найдете репро».

тс просил привести пример, я привел

glib вполне себе реальный проект, который многие используют

уверен, что таких проектов можно найти довольно много, особенно в какой-нибудь проприетарщине (по собственному опыту)

MFC? Конечно, можно полагать, что все исключения унаследованы от std::exception, но всё равно полезно иметь catch(...) обработчик на самом высоком уровне, если не хочешь, чтобы твоя программа просто падала, когда выбросится что либо неожиданное.

Ну да, пускай она просто плюнет в консоль ex.what() и тихо завершится без уведомления пользователя.

Я всегда наследуюсь от Exception или RuntimeException.

Это плохой стиль. Когда идет что-то не так, в частности кидается неизвестное исключение, то лучше упасть и переподняться watchdog'ом, а потом проанализировать корку.

2. Вызов 3-rd party code всегда обязан быть обрамлен в catch(...)

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

Да, ты прав.