Лепсик,
Если ты ещё здесь,
Мы пообсуждали эту тему ещё с парнями. Мне было интересно. Ещё разок копнуть, да потрещать на эту тему. То хорошие программеры. Надо сказать, что к единой точке зрения, как бы мы и не пришли, если рассматривать вопрос об экзепшн и глобально и с практической точки зрения.
Наверное, в конкретном случае надо сверяться с имплементацией SUH:
http://www.microsoft.com/msj/0197/excep ... ption.aspx
Ты, конечно же прав, когда говоришь, что в большинстве случаев программируя на С++ легко перехватить и обработать экзепшн (что происходит внутри DLL) в вызывающем коде. Хотел, бы отметить, то, что в первом посте было написано –
В ОБЩЕМ СЛУЧАЕ (т.е. всегда)
НЕВОЗМОЖНО. Т.е. в большинстве случаев (особенно, если программируется всё в одной среде – и DLL, и вызывающий код), таки да… Всё перехватывается и ловится.
Но вот, ниже, пример хакания самого себя в особо извращённой форме в DLL:
Код: Выделить всё
//простая функция DLL, где екзепшн связан с обращением к не проинициализированному указателю
// except.dll
#define EXCEPT_API extern "C" __declspec(dllexport)
EXCEPT_API int __stdcall fexcept( void )
{
int rc;
char * s;
memset( s, 0, 1024 );
rc = atoi(s);
return rc;
}
В консольном приложении test.exe эта функция DLL вызывается, как:
// test.exe
typedef int (__stdcall *pEXCEPT_FUN) ( void );
try
{
pfunc();
}
catch(...)
{
_tprintf(_TEXT("Good. We are in catch (...)\n"));
FreeLibrary(hlib);
return;
}
Если и except.dll, и test.exe изготовлены в одной IDE – проблем не возникает.
Особенно не возникает проблем, если это VS.NET.2003. В этом случае, исключительная ситуация (просто очень исключительная в данном случае) в except.dll отлавливается в test.exe – всё работает нормально.
Но!
1) Если скомпилировать except.dll ( full release ) в Borland C++ Builder 6.0, a test.exe в VS.NET 2003 –
то test.exe
_ПРОСТО_МОЛЧАЛИВО_УМИРАЕТ при вызове pfunc(). Даже диалога о недопустимости операций не покажется.
2) Поведение вызывающей программы test.exe ещё зависит не только от того, каким компиллером собрана except.dll, но и с какими опциями – DEBUG, или RELEASE. Впрочем, поведение test.exe будет также зависеть от и опций проекта самого test.exe. (DEBUG, или RELEASE). Может и по неопытности, но я натыкался давно (конечно же в других программах), когда в DEBUG всё работало, а в RELEASE – валилось приложение…
И последнее…. DLL может быть вызвана не только из программы, написанной на С++. Это может быть и VB/VBA. В этом случае описанная «неодинаковость» обработки исключений при использовании разных компиллеров С++ - усугубляется. Необработанность исключения внутри DLL – почти всегда приводит к анормал терминейшн VBA программы. Хотя возможно, я плохо программрую не только на C++, но и на VB. ;(
Посему, вот моя точка зрения (допускаю, что тебе она совершенно по бороде):
1) Если собираем всё в одном и том же языке программирования и используем одну и туже IDE – то экзепшн отлавливается без проблем.
2) Если, предполагается, что DLL будет использована в разных языках программирования (в вызываеющем коде), обязательно обрабатывать исключения внутри самой DLL, где только можно, а возвращать код ошибки. Не надеясь, что экзепшн может быть обработан в вызывающем коде.
3) Народ неоднозначно (если говорить о глобальном концепсьёне) отнёсся к рациональности анализа в вызывающей программе кодов ошибок (хоть то HRESULT, хоть ещё что…). Напомнили историю с оператором new в C++. В связи с этим, и как бы ты не обрабатывал исключительные ситуации внутри кода функций ДЛЛ, хорошие программеры советуют вызывать функции ДЛЛ в try блоке, а не ограничиваться только анализом кода возврата. Для меня это остаётся спорным.
4) И последнее. Если во главу угла ставить переносимость бинарного кода, то современные компиллеры, пока что не позволяют всегда и однозначно перехватывать экзепшн в коде сделанном прои помощи других компиллеров. Это даже не моё мнение. Но я с ним согласен, ибо натыкался на эти грабли чисто по-ламерски.
Вот такие, Лепсик, дела с простым вопросом….
Про Экзепшен.
кроме как пинать авторов