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

Итак, у нас есть исключения C++

try
{ // something useful }
catch(exception& e)
{}
catch(...)
{  // point X }

Проблема 1: как в точке 'X' определить тип исключения?
Штатных методов не знаю, нештатные более-менее понятны, но компиляторо-зависимы и однако же совсем не просты.
С другой стороны, под конкретный компилятор определялку написать можно, но надо время и копацца в байтах.
Если кому-то попадалась что-то готовое, я бы лучше пива выпил.

Проблема 2: неплохо бы ловить асинхронные (SEH) исключения через механизм C++ исключений
При этом трюк с _set_se_translator понятен, как и ключ msvc/icl /EHa.

Однако ж интересно, без установки транслятора что там ловится, в этом catch(...){} (а оно ловится в случае с /EHa)
И можно ли в этом случае получить информацию о коде ошибки SEH (т.е. то, что доступно через механизм обработки исключений SEH).

Кроме того, опять же, _set_se_translator действует в пределах потока.
Т.е. это что, если мы попытаемся использовать эту методу в нескольких независимых dll, мы видимо получим конфликт?

---

А цель-то вообщем простая - ловить адресно, не прибегая к ковровым бомбардировкам.
Поэтому для C++ исключений в итоге будет переносимо, ибо определив тип прилетающего исключения, я пропишу для него отдельный блок.

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

Uzhast писал(а) 30. Октября 2007 :: 18:57:

О, классно, спасибо.
Я утром на rsdn видел, как кто-то эту ветку искал, да сама не попалась.

Цитата:

Дык беда в том, что в одной функции нельзя использовать __try/__except и try/catch одновременно.
А это иногда совсем не круто.
И в принципе, это удобно, когда в едином стиле ловятся и деление на ноль и bad_alloc.
Они же ничем не отличаются, если не смотреть сквозь дыры абстракций.

kms писал(а) 30. Октября 2007 :: 11:46:

Согласен, и очень доволен vs8 отладчиком в этом плане.
Но захотелось разобраться, как он это делает и ничего ли не утаивает

Цитата:


С транслятором, в принципе, я вижу только одну проблему.
Предположим, мы с тобой пишем по модулю.
Ты используешь у себя _set_se_translator и я тоже.
При этом для деления на ноль ты бросаешь какой-нибудь CDivisionByZero, а я бросаю CVeryBadDivision.
В итоге либо в один, либо в другой модуль будут прилетать чужие исключения, что, я думаю, отрицательно скажется на кислотно-щелочном балансе.

А так все довольно готичненько.

---

Кстати, вот еще одна обалденная статья на тему реализации обработки исключений под windows.
http://www.codeproject.com/cpp/Exceptionhandler.asp?df=100&forumid=3666&exp=0&se...

Большая часть соответствует действительности.

И, в принципе, довольно легко оказалось определить тип исключения в блоке catch(...)
Если рассматривать блок catch(...) как некую функцию, то она имела бы сигнатуру на моей системе

void* __cdecl catch_and_return_next_eip(
         _EXCEPTION_RECORD *pexc_rec,
         EXCEPTION_REGISTRATION  *preg_frame)

Отсюда много чего можно получить, и все то, что мне нужно было там тоже есть.
В EXCEPTION_REGISTRATION для SEH исключений есть код и адрес исключения, а для cpp исключений есть сам объект исключения, да если захотеть, то и type_info для этого объекта можно найти через структуру excpt_info.

Короче, если бы отладчик по-прежнему ничего не умел, я бы щаз блеснул.
А так все же пойду пиво пить.

Это да.

Вообще, совместимость модулей - это большая тема, и чем ближе подходишь, тем она больше.
Исключения C++, распределение памяти, структуры данных (кроме POD) - все может оказаться несовместимым.

Цитата:

О. Отличное название. Подождите, я записываю
Ну типа да, идея в том, чтобы сделать непереносимый платформозависимый модуль транслятора SEH, который бросает нормальные исключений С++ (а их обработка уже переносима).

Цитата:

Тут меня печалит несколько другой момент.
Предположим, мы в двух совместимых модулях независимо используем _set_se_translator
При этом в одном модуле пишем

static void se_translator(unsigned int code,_EXCEPTION_POINTERS *)
{
if (code == EXCEPTION_FLT_DIVIDE_BY_ZERO)
   throw CDivideByZero();
}
дальше где-то
try
{
// something useful
}
catch(CDivideByZero& e)
{
// handler
}
 

В другом модуле - все то же самое, но не CDivideByZero, а какой-нибудь CFckngDiv.

В итоге, модуль, который загружается вторым, переопределяет se_translator на свой, и в первый модуль начинают прилетать не CDivideByZero, а CFckngDiv, что соответствующим образом влияет на общий анамнез.

Есть вероятность, что здесь есть какие-то тонкости, но на первый взгляд этот механизм, либо надо использовать единолично, когда больше никто не использует, либо использовать один se_translator на все модули, либо не использовать вообще.

Цитата:

Я вообще-то ничего такого на замышлял.

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

Мне надо обрабатывать ошибки арифметики с плавающей точкой + целочисленные деления на ноль.

Выхода тут 3.

1. Ручная проверка допустимости параметров (0, <0, isnan, finite и т.п.)
2. Использование __try/__except
3. Использование _set_se_translator + трансляция SEH в cpp + try/catch для транслированных исключений cpp.

Везде, как водится, свои плюсы и минусы.
Короче, стою, и вспоминаю: налево пойдешь - xxx направо пойдешь - xxx прямо пойдешь - xxx, а слишком долго думать будешь - прямо здесь - xxx