Ребята. У меня такая проблема. Пишу компилятор в виде одной DLL. В некоторых случаях надо выпрыгнуть из стека системных вызовов (ошибка чтения из временного файла и т. д.). Вызываю — exit, выскакивает исключение. Как лучше поступить в данном случае.

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

H_C>Ребята. У меня такая проблема. Пишу компилятор в виде одной DLL. В некоторых случаях надо выпрыгнуть из стека системных вызовов (ошибка чтения из временного файла и т. д.). Вызываю — exit, выскакивает исключение. Как лучше поступить в данном случае.
Я бы просто повесился.

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

H_C>Ребята. У меня такая проблема. Пишу компилятор в виде одной DLL. В некоторых случаях надо выпрыгнуть из стека системных вызовов (ошибка чтения из временного файла и т. д.). Вызываю — exit, выскакивает исключение. Как лучше поступить в данном случае.


Я конечно не знаю, но по моему ты что-то делаешь не то. Компилятор это как бы нечто содержащее высокоуровневую прикладную логику
и при чём тут такие низкоуровневые веши как стеки сиетемых вызовов да ещё и чтение файла?


А также очень плохо в DLL использывать "exit" и тому подобные веши относящиеся ко всему процессу.

Вообще то DLL лучше проэктирывать так чтобы не нужно было её выгружать в случае аварии какой-то одной
функции. Особенно это касается многопоточных DLL.

Кроме того, если уже какая-то фунция грохнула всю DLL, то она должна об этом сообщить тот модуль, который
эту DLL и загрузил, чтобы он её и выгрузил и отметил у себя про это. Иначе если DLL сама себя выгрузит,
но тот модуль, который её загрузил и который её юзает ничего про это знать не будет, тогда он обратиться по несуществующим адрессам и.т.п.
и произойдёт завал общий.

А общем всё надо делать как можно проще.

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

H_C>Ребята. У меня такая проблема. Пишу компилятор в виде одной DLL. В некоторых случаях надо выпрыгнуть из стека системных вызовов (ошибка чтения из временного файла и т. д.). Вызываю — exit, выскакивает исключение. Как лучше поступить в данном случае.
Если надо "выпрыгнуть" из экспортированной длл функции, то бросай структурное исключение (RaiseException), оно способно проходить через границы модулей в отличии от С++ исключений (правда это сильно зависит от компилятора). Кстати по этому поводу лучше каждую экспортируемую функцию оборачивать в try-catch, чтобы ненароком они не выскочили
Соответственно, на вызывающей стороне __try-__except (msvc).

Здравствуйте, Vain, Вы писали:
V>структурное исключение (RaiseException), оно способно проходить через границы модулей в отличии от С++ исключений (правда это сильно зависит от компилятора).
Это не от компилятора а от сборки зависит. Просто всё должно быть собрано с одинаковой версией рантайма и включенной поддержкой исключений — тогда нет никакой проблемы кидать нормальные С++ные исключения. Все нормальные библиотеки так делают...

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

Z>Здравствуйте, Vain, Вы писали:
V>>структурное исключение (RaiseException), оно способно проходить через границы модулей в отличии от С++ исключений (правда это сильно зависит от компилятора).
Z>Это не от компилятора а от сборки зависит. Просто всё должно быть собрано с одинаковой версией рантайма и включенной поддержкой исключений — тогда нет никакой проблемы кидать нормальные С++ные исключения. Все нормальные библиотеки так делают...
Разные компиляторы могут по разному реализовывать C++ исключения, нет никакий гарантии что исключение выброшенное dll, которая собрана к примеру gcc будет поймано в exe, которое собрано, к примеру, comeau и т.д.

Человек пишет компилятор. Эту dll в дальнейшем могу использовать с любым языком программирования.
Не рекомендуется ф-ями dll возбуждать исключения, по понятным причинам. Обработка исключений у каждой компании своя.
Это комерческая тайна; так же как и работа dynamic_cast в C++.
Ему нужно при работе его компилятора, т.е. в процессе разбора кода, тормознуть этот заблудившийся в дебрях парсер. Вот он и спросил про это. Если только автоматы компилятора строить нормально, корректно обрабатывать все ошибки внутри самой dll.
TerminateThread тебе возможно поможет завершить ф-ию потока, почистив стек.

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

C>TerminateThread тебе возможно поможет завершить ф-ию потока, почистив стек.

Не чистит он стек, хотя можно руками

Автор: gear nuke
Дата: 27.08.06

.

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

C>>TerminateThread тебе возможно поможет завершить ф-ию потока, почистив стек.
GN>Не чистит он стек, хотя можно руками

Автор: gear nuke
Дата: 27.08.06

.
Зачем руками, пусть бросает исключение C++, а на границе exe-dll, т.е. внутри экспортируемой функции dll ловит и переребрасывает дальше через RaiseException.

Здравствуйте, Vain, Вы писали:
V>Разные компиляторы могут по разному реализовывать C++ исключения, нет никакий гарантии что исключение выброшенное dll, которая собрана к примеру gcc будет поймано в exe, которое собрано, к примеру, comeau и т.д.
ABI и стандарта манглинга для С++ до сих пор не существует, так что если у dll С++ интерфейс, то значит и линковать его будет с другими модулями собранными тем-же компиляторам. А тогда, соответственно можно пользоваться исключениями и всеми остальными механизмами. Если-же нужно кроскомпиляторная бинарная совместимость, то тогда нету другого выбора, кроме оборачивания модуля в С интерфейс, и тут естественно, ни какие исключения не должны вылетать.

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

C>Эту dll в дальнейшем могу использовать с любым языком программирования.
Только если у длл С-интерфейс. См. мой ответ Vain-у выше.

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

Z>Здравствуйте, Vain, Вы писали:
V>>Разные компиляторы могут по разному реализовывать C++ исключения, нет никакий гарантии что исключение выброшенное dll, которая собрана к примеру gcc будет поймано в exe, которое собрано, к примеру, comeau и т.д.
Z>ABI и стандарта манглинга для С++ до сих пор не существует, так что если у dll С++ интерфейс, то значит и линковать его будет с другими модулями собранными тем-же компиляторам. А тогда, соответственно можно пользоваться исключениями и всеми остальными механизмами.
Это тоже надо проверять, гарантий что модули разных версий одного компилятора будут подходить к друг другу тоже пока я не встречал.
Я бы с этим не стал особо заморачиваться, сделал по уму и забыл.