try {
if( mFileNames0 == 0 )
return 0;
}
catch(exception b)
{
return 0;

при попытке исполнения if( mFileNames0 == 0 ) получаю ошибку чтения по адрессу 0х00000080 и не страбатывает исклчение, что делать?

cString* mFileNames0;

-----
-=истина где-то рядом=-

| Сообщение посчитали полезным:

не может такого быть

может все таки подразумевался if( *mFileNames0 == 0 ) ?

| Сообщение посчитали полезным:

да нет, подразумевается именно то, что написано в коде. Исключение тупо не срабатывает.

-----
-=истина где-то рядом=-

| Сообщение посчитали полезным:

исключение и не должно срабатывать

а для ловли того что вы хотите вам нужны другие виндовые ловли исключений
__try
__finally

| Сообщение посчитали полезным: KingSise

Си++ исключения не ловят исключения процессора. Они ловят всякие там throw. Но это я очень грубо выразился. Читайте описание __try и try методов.

| Сообщение посчитали полезным:

int
Ловят-ловят. Только для этого в проекте надо ключ выставить (для студии) /EHa. И ловиться будут всякие иксепшены, даже если они и не были через throw выброшены, правда, для этого надо использовать конструкцию catch(...).

reversecode пишет:
а для ловли того что вы хотите вам нужны другие виндовые ловли исключений
__try
__finally

Подойдёт и _try ... __except. Но некрасиво. И, как бы, --> _set_se_translator <-- всё-таки выглядит несколько лучше.

И никто не читает мой блог (пичаль). --> Тут уже было<--

-----
Stuck to the plan, always think that we would stand up, never ran.

| Сообщение посчитали полезным:

да я только наводку дал,
тем более не надо миксить стандартные с++ try итд, с M$-овскими вариациями
кросс платформенность убивается

| Сообщение посчитали полезным:

ARCHANGEL
Да я уже и не помню всех этих тонкостей. Кроме того, как уже правильно написал reversecode есть стандарт. И есть компании, работая в которых вы будете получать пизд**ей за нарушения стандартов. Хороший код работает везде где угодно, собирается любым компилятором и работает стабильно (кроме system specific задач). Я уже три года пишу софт в основном только под линукс и исключений у меня там не возникает. Писать надо уметь без исключений. Линукс очень хорошо воспитывает это (just google for segmentation fault). И не надо писать тут, что код получается не красивым. Пара проверок всяко красивее, чем переключения ring3 -> ring0 -> ring3 с вызовом десятков процедур для обработки исключений.

И да, прочитал ваш блог, вам F_a_u_s_t уже все объяснил.

| Сообщение посчитали полезным: dosprog

KingSise,
глюк при компиляции?...
Чтобы понять, в чём дело, я бы добавил (временно) проверку вроде такой:
if( &mFileNames0<400000) {/*Тут вывод сообщения, что какая-то лажа*/....;}
...нужно пробовать.

--ADD--
Archer,
1) согласен, верно будет 10000.
2) обычный if - так проще всего. Тем более, что потом это всё равно нужно удалить.




| Сообщение посчитали полезным:

dosprog
Не совсем понятно, откуда взялось 400000, коль это динамически выделяемая память, уж тогда брать нижнюю невыделяемую границу в 0x10000. А во-вторых, для этого assert есть.
KingSise
А тут мне непонятно, откуда обращение к члену даёт ошибку чтения по адрессу 0х00000080. Сдаётся мне, это обращение в несуществующий экземпляр класса. И надо бы проверку делать где-то раньше, либо вообще такую бяку не писать, походу, проектирование хромает.

| Сообщение посчитали полезным:

Archer пишет:
Сдаётся мне, это обращение в несуществующий экземпляр класса.
Я бы сказал код вырван из контекста. Можно делать очень много предположений на тему того, откуда ноги растут. И не факт, что именно mFileNames0 вызывает исключение, это лишь предположение автора, который явно не до конца понимает суть проблемы исключений. Я вот например не понимаю, откуда там вообще может быть исключение, если это обычный указатель, который проверяется на ноль - все вполне законно. Ошибка может быть где-то выше.

| Сообщение посчитали полезным:

int,
это испорченный, неверный указатель (сама переменная). Даже не "указатель в никуда". Ошибка компилятора или ошибка программиста.
Archer верно описал возможную причину.

Например, в самом простом случае, всё выглядит промерно так:

char* pStr = "Hello";

Тогда:
&pStr == 0x490000 (например) - зависит от компиляции (!) - Переменная времени компиляции - Дальше константа времени выполнения - Указатель на указатель на строку "Hello"
pStr == 0x650000 (например) - зависит от компиляции - Переменная - Указатель на строку "Hello"
*pStr == "Hello" (точно!)

В примере глюка у KingSize &pStr==0x80. Естественно, обычной программе оттуда читать ничего нельзя.

P.S. Это всё в Си-шной терминологии. Не вдаваясь в ++.


--ADD-- К следующему посту,
int,
да. Я малость всё усложнил.




| Сообщение посчитали полезным:

dosprog пишет:
&pStr==0x80
А где вы видите там амперсенд? reversecode специально переспросил про форму записи обращения к переменной. Указателю я могу присвоить что угодно и все хорошо, пока я не обратился по указателю. Ссылаться я могу хоть "в космос", фолт возникает, когда выполняется что-то вроде mov ebx, [edi], где edi равен 0x80. Но я слабо представляю, как может возникнуть фолт на инструкции mov ebx, edi или lea ebx,[edi].

| Сообщение посчитали полезным:

ARCHANGEL пишет:
reversecode пишет:а для ловли того что вы хотите вам нужны другие виндовые ловли исключений__try__finally

вот ответ на мой вопрос ;) Все получилось и работает отлично.

сделал так и все работает:




-----
-=истина где-то рядом=-

| Сообщение посчитали полезным:

KingSise,
.. то-есть, срабатывает __except(EXCEPTION_ACCESS_VIOLATION).
ну, что-ж...
Лучше бы найти ошибку (как и сказал int), а не "переваливаться" через неё. Впрочем, хозяин - барин.

P.S.
"if((int) &mFileNames0 < 0x010000 )" - нужно было проверять до "if(mFileNames0 ==0 )"
ну, да ладно.




| Сообщение посчитали полезным:

KingSise пишет: Все получилось и работает отлично.
Скверное решение, где можно обойтись без капитуляции ( сепшенов ) там нужно обходится без нее.
Причины до тупого просты, с условиями код нагляднее, код должен контролироваться там, где это возможно и так же, должен быть предсказуем, а значит, он должен решаться условиями.
Сепшены нужны в редких случаях, когда контролировать результат затруднительно или вообще невозможно, все остальное, это ошибки проектирования.
Дело в том, когда проект изначально маленький, то код зачастую пишется небрежно, но по истечению времени, он начинает разрастаться, а старые костыли, как правило никто не убирает и в итоге каша вместо кода.
Это не говоря о том, что исключение может вызываться в одном месте, а обрабатываться в другом и мягко говоря, можно устать от беготни по обработчикам.
За __try.. уже говорил, для большинства задач достаточно стандартных try..
Итог, лучше заняться редизайном, а не подпирать костыли костылями, дальше будет больше и когда то это все рухнет.

| Сообщение посчитали полезным:

mFileNames0 видимо мембер класса, когда самого класса нет (this невалидный или нулевой) тогда ексепшен который мы наблюдаем

| Сообщение посчитали полезным:

ртловские фолты никакого отношения к железячным не имеют. Эта хуита вообще не понятно зачем придумана.

| Сообщение посчитали полезным:

int пишет:

Я уже три года пишу софт в основном только под линукс и исключений у меня там не возникает. Писать надо уметь без исключений. Линукс очень хорошо воспитывает это (just google for segmentation fault). И не надо писать тут, что код получается не красивым. Пара проверок всяко красивее, чем переключения ring3 -> ring0 -> ring3 с вызовом десятков процедур для обработки исключений.

Не, ну это ещё можно как-то понять, линукс, может, и воспитывает это - я не пробовал, не могу судить. Но смысл в исключениях есть. А вот это уже не лезет ни в какие ворота:

Dr0p пишет:
Эта хуита вообще не понятно зачем придумана.

Книга --> Чистый код. Создание, анализ и рефакторинг<--

с.132-133.



--> Ссылка на книгу для ознакомления<--

-----
Stuck to the plan, always think that we would stand up, never ran.

| Сообщение посчитали полезным:

в линуксе тоже можно перехватывать сегфолыт и прочее, просто M$ это окучило под обработку исключений, что бы удобнее было пользоваться

| Сообщение посчитали полезным:

reversecode пишет:
mFileNames0 видимо мембер класса, когда самого класса нет (this невалидный или нулевой) тогда ексепшен который мы наблюдаем

Так и есть, не проверил создан ли класс. Как оказалось при некоторых условиях он не создается и проверка нужна.

-----
-=истина где-то рядом=-

| Сообщение посчитали полезным:

ARCHANGEL

Ну и что дальше ?

Ответа я не вижу. Среда генерит какие то виртуальные фолты, их должен обработать скрипт, а если не может, то всё отваливается к ём. Тут логический вывод один - говнище, как среда так и её рудименты.

| Сообщение посчитали полезным:

KingSise пишет:
Так и есть, не проверил создан ли класс. Как оказалось при некоторых условиях он не создается и проверка нужна.

На этот случай в конструкторе при невозможности создания объекта бросается исключение. Далее по стандартной схеме try/catch/finally, но уже без обращения по нулевым указателям.

-----
Следуй за белым кроликом

| Сообщение посчитали полезным: