Всех приветствую !
Наткнулся на одну проблемму , пока не пойму где собака зарыта

Вообщем дело вот в чём :

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

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

Вроде всё логично, и проблемм не должно быть . Но не тут то было
Недавно столкнулся с такой фишкой, что бывают такие ошибки , каторые ON ERROR не перехватывает
Т.е. вылолняется не моя процедура обработки ошибки, а простое фоксовое сообщение , для примера :
---------------------------------
Ошибка программы
---------------------------------
"Недопустимая рекурсия при вычичлении правила"
---------------------------------
Т.е. в этом случае таблицы не разблокируются, и выполнение всех программ останавливается до тех пор пока пользователь ручками не закроет это окно .

Теперь сам вопрос:
Что это за такие особенные ошибки, не перехватываемые ON ERROR ?
И можно ли, их всётки както обуздать ?

PS VFP 8, Windows XP



Отредактировано (10.02.05 17:53)

А зачем ты блокируешь всю таблицу? Блокировал бы одну запись rlock().

Приветствую !

2Saratoga
Спасибо за ответ .
У меня одна процедура блокировки для всех случаев .
Т.е. здесь может быть и прямое изменение одной записи (REPLACE), в этом случае , как вы правильно сказали, более оптимально было бы блокировать одну запись.
Но такая ситуация скорее исключение, чем правило . В основном в таблице меняется не одна запись, а набор записей по условию, или удаляются/добавляются записи .
Т.е. вариант с блокировкой отдельных записей не проходит
Меня больше интересует не вопрос оптимизации алгоритма блокировок , а именно проблема с обработчиком ошибок, описанной мной выше .

Может не обработчиком ошибок в таком случае пользоваться а пытаться блокировать записи руками и тут уже принимать решения если блокировка не прошла ?



2000 пост однака http://piva.fatal.ru/smile/50.gif



Отредактировано (11.02.05 09:42)

Вадим.

Что-то есть в вопросе, помниться эксперименты с FLASH показали, что ошибка фоксом вообще никакая не возвращается, только ОС говорила про потерю коннекта.

Вот пример когда не обрабатывается ни ON ERROR, ни правило поля


похоже, что ошибка квази компиляции (интерпритации) на стадии выполнения не перехватываются.

Паша, вопрос конечно интересный, но как ты думаешь как может выполнится обработчик ошибок, когда достигли глубины вложенности вызова процедур - куда еще дальше обрабатывать, раздвинуть глубину вложенности ?
http://piva.fatal.ru/smile/62.gif

Цитата:

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

Конечно же понятно, что это выход за ограничение среды и править надо сам код и не пинять на ON ERROR, просто сам факт что пользовательский ON ERROR не главный (вроде как в самой процедуре мы ошибок не сделали), а происходит его переопределение на фоксовский, немного не соответствует хелпу, либо что-то мы не знаем и есть некий приоритет в обработке пользовательского и системного Error.

Вообщем , пишите без ошибок (благое пожелание)

Всез приветствую !
И Всем огромное спасибо за ответы ............
Только вот проблему так и не решили
Ну ладно, с переполнением рекурсий я понял , остаётся только более глубоко анализировать код на возможность возникновения подобных ситуаций.
И предотвращать их на этапе разработки . Что конечно более правильно, изночально
Но у меня вопрос . Такие ошибки ( не перехватываемые ON ERROR) могут быть связанны только с превышением вложенности процедур/функций ?
Иль существуют ещё какийнить моменты, при которых можно ждать подобное поведение программы ?

Про FLASH, уже написал, есть ошибки так назывемого смешанного характера, зависящие от всего комплекса ПО и вычленить сам фокс не в состоянии , например ошибка 5115 Write failed, а что конкретно отвалилось , сам понимаешь надо разбираться.

Цитата:

Иль существуют ещё какийнить моменты, при которых можно ждать подобное поведение программы ?

По этому поводу у Леса Пинтера есть замечательная фраза в вольгом переводе: "Ошибок не существует в принципе, а есть ситуации для которых программист не предусмотрел проверки"

Hi, melnik!

Ручная блокировка - зло.
Блокировка ВСЕЙ таблицы - многократное зло.
Невыверенный код (неограниченные рекурсии, fuzzy logic и т.п.) выполняющийся
при заблокированных таблицах - зло.
Теперь думай, ЧТО нужно изменить в логике программы, чтобы всего этого зла
избежать

P.S. Я уж молчу про тупики, классическую ситуацию возникающую при
блокировках одновременно нескольких "ресурсов" (таблиц или записей -
неважно).

P.P.S. Конечно же есть ситуации, когда ручные (в т.ч. "табличные")
блокировки нужны, но таких ситуаций настолько немного, что даже как-то не
охота про них говорить... И конечно изменение "группы записей" о общем
случае ещё не повод накладывать табличную блокировку.