Об исключениях

[metaclass]

Windows Imaging Component от разработчика Микрософт.

Все более-менее понятно, кроме двух вещей:
1) Почему обязательно COM, а не flat API с хендлами?
2) Почему нельзя использовать исключения?

Фиг с ним с COM, это какая-то странная микрософтовская религия, но вот про исключения я не понимаю. Такое ощущение, что в С/С++ какие-то есть тонкости с исключениями, которых я не знаю и которые мешают их использовать.

По-моему, в начале метода гораздо проще выполнить проверки и кинуть исключение, которое обработается там, где юзер нашего API знает, что с ним делать, или показать пользователю сообщение об ошибке, которое будет показано тому, кто знает что с ним делать, чем проверять на каждом уровне вызовов коды возврата ВСЕХ вызовов, которые могут вернуть ошибку.
Причем try finally, по-моему, более простой вариант очистки выделенных ресурсов, чем куча goto и проверок.

UPD: Насчет исключений разъяснили. В c++ try/finally конструкция нестандартная, а вместо нее используется RAII (который еще и менее многословен, вообще-то).

Comments

[(Anonymous)]

у гугла тоже такая же ботва

[jek-hor.livejournal.com]

Погоди, а как с помощью исключений обрабатывается случай с ошибкой в середине последовательных выделений ресурсов?

[max-posedon.livejournal.com]

RAII

[metaclass.livejournal.com]

Этот паттерн внутри компилятором преобразуется в обработчик исключений, насколько я себе эту кухню представляю. Т.е. при любом варианте выхода из блока видимости созданные объекты грохаются деструкторами.

[max-posedon.livejournal.com]

Ничто не во что не преобразовывается, но вывод верный.

[metaclass.livejournal.com]

Преобразовывается в что-то похожее на try-finally . Так как иначе при кидании исключения из блока не будут разрушены созданные объекты.
Да, надо вообще ради интереса скомпилировать и в IDA глянуть, потому что-то я давно смотрел и тонкостей не помню.

[metaclass.livejournal.com]

Я предварительно ссылки на ресурсы делаю нулл перед try, внутри try создаю, а затем в финалли грохаю те, которые не нулл, в обратном созданию порядке.

[jek-hor.livejournal.com]

Ага, т.е., от пачки ифов всё равно никуда не денешься :) Да и не всегда выделению ресурсов соответствует переменная (например, регистрация чего-нибудь в системе).

[metaclass.livejournal.com]

Если нет переменной - то как тогда определить выделился ли ресурс или нет и грохнуть его?
Это и с исключениями и с ручной обработкой одинаковая проблема будет.

[jek-hor.livejournal.com]

{
int err;

err = do_some_work1();
if (err)
goto work1_failed;

err = do_some_work2();
if (err)
goto work2_failed;

return 0;

undo_work2();
work2_failed:
undo_work1()
work1_failed:

return err;
}

Как-то вот так.

[kkirsanov.livejournal.com]

Про эксепшены - http://www.rsdn.ru/forum/message/2821905.1.aspx

[max-posedon.livejournal.com]

Потому что исключения и COM несовместимы.

Вот допустим по поводу полнолуния, захотел повызывать COM-вызовы из... Xslt преобразований, как мне там исключения обрабатывать?...

[max-posedon.livejournal.com]

Я бы предпочал освобождать ресурсы в деструкторах wrapper-ов(RAII), а не в try finally (который мне непонятно зачем нужен, да ещё M$ specific)

[metaclass.livejournal.com]

Эээ, как это он MS specific. try finally стандартен везде, по идее.

[max-posedon.livejournal.com]

А вот так, нет try finally в стандарте С++,

http://msdn.microsoft.com/en-us/library/9xtt5hxz(VS.80).aspx

[metaclass.livejournal.com]

Все ясно. Поэтому их и не используют.

У меня код содержит дофига finally, но гораздо меньше catch. Я бы мог использовать RAII для этого же случая, но .NET это дело не поддерживает (вернее там свой стиль для этого, с using IDisposable), а дельфи поддерживает только для COM-интерфейсов, которые я делать не люблю, т.к. мне проще руками управлять созданием и разрушеним объектов(я так лучше понимаю, кто чем владеет).

[8vmr.livejournal.com]

<Потому что исключения и COM несовместимы.
Плохо вы COM знаете...

СОМ-сервер не может кинуть исключение напрямую, да. Но вот вернуть HRESULT, по результату которого уже клиент запросит детальную информацию (IErrorInfo - http://msdn.microsoft.com/en-us/library/ms221233.aspx) и "перекинет" новое исключение (уже на клиентской стороне)

делается просто:
OLECheck(COMObject->InvokeMethod());

OLECheck просто проверяет HRESULT и, если надо, кидает правильно настроенный экзепшен

PS: А еще этот механизм называют safecall

[max-posedon.livejournal.com]

Возвращение результата с которым мне потом надо возится это никапли не исключение. А то по вашим словам даже C Posix API получается поддерживает "исключения".

То что вы описали, это просто механизм обработки исключительных ситуаций, и не волнуйтесь я вкурсе того как это делать, даже на plain C.

[8vmr.livejournal.com]

>и не волнуйтесь я вкурсе того как это делать
я не волнуюсь :)

[ykaliuta.livejournal.com]

куча goto и есть исключения руками (а что за куча проверок?), если мы об одном и том же. Но обычно не куча а 3-5.

[metaclass.livejournal.com]

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

А исключения - это throw, try, finally, catch

[ykaliuta.livejournal.com]

найдите десять отличий (с)

[rezkiy.livejournal.com]

расскажите мне как без СОМ или чего-то ему подобного делать аналог аут-оф-прок комобъектов?

[metaclass.livejournal.com]

Только ради out-of-proc тащить всю эту инфраструктуру COM с регистрацией в реестре и библиотеками типов в софт меня чем-то пугает. Пройдутся психи-пользователи "оптимизаторами реестра" и все, кранты работе софта.
По-моему, COM излишне усложнен, но реализацию клиент-серверного взаимодействия между процессами на низкоуровневых языках по другому и не сделаешь, скорее всего.

[rezkiy.livejournal.com]

RPC не в пример проще, особенно его локальный вариант. Не надо использовать COM тогда когда можно обойтись RPC (на котором к слову COM построен). Даже я про это пишу вот тут http://rezkiy.livejournal.com/38839.html

[1ceheart.livejournal.com]

Мне тут недавно один разработчик доказывал, что в драйвере можно использовать try/catch (и finally, разумеется), с пеной у рта практически. Аргументация была железная - "ну я же пишу драйвер на C++! А в C++ есть исключения! Значит, должны быть исключения!".

Ситуация не та, конечно, но если есть возможность не использовать C++ exceptions, их не надо использовать. Имхо.

А COM, я думаю, потому что threading model и маршалинг сразу автоматически, это удобно.

[rezkiy.livejournal.com]

Можно. Помотрите на пример использования функции ProbeForRead()

[1ceheart.livejournal.com]

Это не C++ exceptions, это SEH, которое проприетарное микрософтовское.

[rezkiy.livejournal.com]

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

Кстати в статье про SEH (этой http://msdn.microsoft.com/en-us/library/aa489626.aspx) прямым текстом написано:

Note that structured exception handling is distinct from C++ exceptions. The kernel does not support C++ exceptions.

[volodymir-k.livejournal.com]

COM это апи на уровне "из эксель бейсика вызывать", а не на уровне "красноглазый фрик борется с компиляторами." Ком это прогресс и цивилизация.

[zamotivator.livejournal.com]

RAII предоставляет _уникальные_ средства для разработки.
Без дураков - я такого больше не видел ни в одном языке программирования.
Суть его очень проста и банальна - на _стеке_ создается некоторый объект, в конструкторе которого производиться захват ресурса, а в деструкторе - освобождение.
Например,

{
boost::scoped_lock lock( some_mutex ); // захватили мьютекс. В деструкторе освободим. Где бы ниже исключение не вылетело - он не останется висящим
std::shared_array< char > text( new char[ 100 ] ); // аналогично
//...

На основе этого построен паттерн "Транзакция"
http://insidecpp.ru/patterns/transaction/

[sarent.livejournal.com]

Говоришь, еще и полнолуние на носу?..
У меня вот тоже крыша едет от этого всего. Встаешь, темным-темно за окном, домой приходишь, темно, на улице травка зеленая и вечный туман. Гадость... (http://www.spacedev.ru)

[stra-taktik.livejournal.com]

Многим в полнолуние не спится... (http://www.insurance-lifes.ru)

[magdiya.livejournal.com]

Полнолуние-полнолуние, куда не плюнь. Да успокойтесь уже, других тем нет что ли... (http://www.upbuilding.ru)