я сейчас для ловли ошибок использую следующий код: SomeApi(...) test eax,eax jz __exit_err ... __exit_err: GetLastError() FormatMessageA(0x00001300,0,eax,0,Temp,0,0) MessageBoxA(0,[Temp],0,0) ExitProcess(0) а если вместо "jz __exit_err" писать int3 и ловить эксепшн в SEH, это нормальное решение, или с ним что-то не так? преимущество такого способа в том что не используется глобальная метка, поэтому лучше переносимость кода, etc
связь в том что библиотечный модуль не должен требовать от главного модуля наличия в нем каких-либо глобальных меток, а плодить свои процедуры error в каждом модуле тоже неправильно
GoldFinch не вполне нормально это когда модуль не имеет своего обработчика ошибок. Фигли юзай тогда UnhandledExceptionFilter и не парься.
Почему? А плодить обработчики SEH с тем же самым кодом правильно? в чём разница? Имхо своя метка error в модуле удобна тем, что можно к стандартному сообщению добавить уточняющую информацию об имени модуля строке с ошибкой и т.п. и никаких недостатков метки по сравнению с seh не вижу.
Не, необязательно SEH, он просто для примера. Речь о том чтобы генерить эксепшн вместо перехода на метку. А SEH-обработчик выводящий сообщение конечно тоже должен быть 1, иначе в самом деле, какой смысл.
)) Лично мне идея замены функции на исключение не нравится, хотя M$ даже при работе с Heap предусматривает режим исключения вместо возврата кода ошибки.
GoldFinch приведенный код не является кодом _обработки_ ошибки. это скорее похоже на хрюк свиньи заживо смываемой в унитаз например, если ты записываешь что-то во временный файл, а места на диске уже нет, то можно создать файл на другом томе или попросить пользователя стереть все ненужное. аналогично, если ты выделяешь N байт под буфер работы с файлом, а памяти нет, то можно либо сократить N в несколько раз, либо освободить другие некритичные буфера, либо же выделить буфер в стеке. это и называется обработкой ошибки. универсальных обработчиков не существует и они тесно связаны с контекстом окружения. в частности, буфер под обработку файла (поиск строки, скажем) с легкостью допускает уменьшение размера без переделки алгоритма, но если нам нужно отсортировать массив и функция сортировки ожидает указателя на блок памяти, а столько памяти у нас нету, то, конечно, возможно, отсортировать массив частями, но ценой существенного усложнения алгоритма. ну а пример приведенный тобой действительно лучше реализовать через call чего-то-там. причем, это что-то может быть реализовано в соседнем модуле.
GoldFinch, а как ты собираешься вызвать int 3 без метки. или ты думал, что это прокатит Код (Text): call SomeAPI int 3 к тому же можно один раз написать обработчик метки __exit_err и вызывать его как библиотечную фунцию из другого модуля, а SEH так не поймаешь - убъют! не вижу смысла дергать попусту исключения. собственно это и вводилось дабы разгрузить обработчик исключений (слишком долго в него вываливается и пытаться понять что же случилось).
Исключения конечно хорошо, но вопрос зачем. В этом ещё есть какой-то смысл для библиотеки (и то большой вопрос). Для кидания исключений в свой же код, смысла не вижу.
GoldFinch аналогично Код (Text): Api(...) test eax,eax jnz @f call error_handler @@: или что еще короче Код (Text): Api(...) test eax,eax jnz error_handler а SEH оставь в покое, он существует для внутренних "аппаратно-системных" исключений!
