Легенда:
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
[C++] Предлагаю подвести черту. 16.08.04 02:42 Число просмотров: 1895
Автор: void <Grebnev Valery> Статус: Elderman
|
Не бейте, ежеле опять скажу ламерство… Перед вердиктом:
Killer, конечно же прав, на мой взгляд, когда он говорит, что в большинстве случаев программируя на С++ легко перехватить и обработать экзепшн (что происходит внутри 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 ( 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 будет использована в разных языках программирования (в вызываеющем коде), то прислушаться к товарищу, void, и обязательно обрабатывать исключения внутри самой DLL, где только можно, а возвращать код ошибки. Не надеясь, что экзепшн может быть обработан в вызывающем коде.
3) Ну и ещё …. В целом предложить товарищу void продолжить изучение мат.части, а на буржуйских девелопперов больше не наезжать. ;))
|
|
|