Здравствуйте, smeeld, Вы писали:

S>Для отладки оно, может, и удобно, хотя в юниксах и без таких SEH-удобств, проблем с отладкой нет.
S>И для продакшен версии такое ныряние в ядро на throw-ах, опциями компилятора, никак не отключается?

Тут дело не в отладке. Передача управления отладчику, если он есть (а отладчик в Win32 это не абы кто, а тот, кто запустил этот процесс с флагом DEBUG_PROCESS) — это лишь один из моментов обработки исключений. Прочти еще раз то, что я процитировал в своем первом сообщении в этом треде, чтобы понять, как вообще исключения в нативных процессах Windows работают. Это переход в ядро и там обработка через стандартный механизм обработки исключений в Windows.

Debug или Release — тут не важно, потому что RaiseException находится в kernel32.dll, а далее идет через ntdll.dll и sysenter, что никакого отношения к Debug/Release не имеет.

Я не знаю, можно ли это как-то отключить или изменить. Если кто-то знает — буду рад услышать.

А вот в других языках исключения могут быть реализованы и без этого механизма. У меня нет сейчас под рукой исходников java — машины, но когда-то я в них копался (openJDK), так вот, вроде как там исключения обрабатываются внутри процесса java машины (jvm.exe) и дальше не идут. Не ручаюсь на 100%, но вроде это так. В принципе так вполне и должно быть : за пределы jvm этим исключениям моей java-программы ходу нет (а нативным есть!), поэтому она и может сама все сделать. В частности, ЕМНИП, NullPointerException в java ловится не как в нативном коде (попробуем *p, при p == NULL) получим исключение и далее как сказано выше), а просто проверкой перед каждой операцией значения ссылки на null. Иными словами, никакого исключения Windows там не происходит, а просто jvm процесс в ходе своей работы обнаружил, что его данные (значение java-переменной) нехорошие, ну и выполнил некую обработку

Здравствуйте, smeeld, Вы писали:

S>Для отладки оно, может, и удобно, хотя в юниксах и без таких SEH-удобств, проблем с отладкой нет.
S>И для продакшен версии такое ныряние в ядро на throw-ах, опциями компилятора, никак не отключается?

Тут дело не в отладке. Передача управления отладчику, если он есть (а отладчик в Win32 это не абы кто, а тот, кто запустил этот процесс с флагом DEBUG_PROCESS) — это лишь один из моментов обработки исключений. Прочти еще раз то, что я процитировал в своем первом сообщении в этом треде, чтобы понять, как вообще исключения в нативных процессах Windows работают. Это переход в ядро и там обработка через стандартный механизм обработки исключений в Windows.

Debug или Release — тут не важно, потому что RaiseException находится в kernel32.dll, а далее идет через ntdll.dll и sysenter, что никакого отношения к Debug/Release не имеет.

Я не знаю, можно ли это как-то отключить или изменить. Если кто-то знает — буду рад услышать.

А вот в других языках исключения могут быть реализованы и без этого механизма. У меня нет сейчас под рукой исходников java — машины, но когда-то я в них копался (openJDK), так вот, вроде как там исключения обрабатываются внутри процесса java машины (jvm.exe) и дальше не идут. Не ручаюсь на 100%, но вроде это так. В принципе так вполне и должно быть : за пределы jvm этим исключениям моей java-программы ходу нет (а нативным есть!), поэтому она и может сама все сделать. В частности, ЕМНИП, NullPointerException в java ловится не как в нативном коде (попробуем *p, при p == NULL получим исключение и далее как сказано выше), а просто проверкой перед каждой операцией значения ссылки на null. Иными словами, никакого исключения Windows там не происходит, а просто jvm процесс в ходе своей работы обнаружил, что его данные (значение java-переменной) нехорошие, ну и выполнил некую обработку