Как обрабатывать исключительные ситуации?

AlexF

Подскажите, как обрабатывать исключительные ситуации? Например, в следующем фрагменте, как мне собщить пользователю, что проблема именно с этим файлом?

Код:

S" D:\SPF\devel\~alf\Test\b.txt" R/O OPEN-FILE THROW CSVFile_ !

Подозреваю, что должно быть слово CATCH, но вот как его использовать? По примерам в папке devel не понял, описание этого слова в src ясности не добавило :( Можно ли проиллюстрировать на примере?

Заранее благодарен :)

mOleg

Код:

 : открыть ( asc # --> handle ) R/O OPEN-FILE THROW ;

   S" .\path\file.f" ['] открыть CATCH  IF  ." ошибка тута произошла" ELSE ." проехали нормально THEN 
 \ --> handle 

AlexF

Ок, понял, спасибо. Необычно

А как получить код исключительной ситуации (ошибки)?

ygrek

Его выдаст CATCH

Код:

['] открыть CATCH DUP IF CR ." код такой-то " . ELSE DROP CR ." всё ok" THEN

in4

А если надо сообщить пользователю и повторить действие открыть в тех же начальных условиях?
А если надо повторить действие открыть с запросом альтернативного имени файла у пользователя?

А если надо в подобной программе откатить сразу несколько слов

Код:

: открыть_файл   S" филе" открыть  прочитать_начало S" филе2" открыть ;
: открыть_железку   подготовиться  открыть_файл  начать_работу ;
...
: начать   открыть_железку  делать1 закрыть_железку ;

при этом каждое из них может и не сработать.
Это после каждого(ну или в конце каждого) ставить CATCH или THROW ?!

Как их правильно оформлять такие ситуации, чтобы сохранить контроль над программой?
Есть ли методики этого?

Hishnik

in4 писал(а):

Как их правильно оформлять такие ситуации, чтобы сохранить контроль над программой?
Есть ли методики этого?

/me молча держит плакат "векторизованные обработчики исключений"

AlexF

Поддерживаю in4. Скажем, в Перле это делается довольно просто:

Код:

open F, 'Data.txt' or warn "Can't open file: $!\n";

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

Код:

FileOpen ( addr u mode -- ior | err_code 0 )

В случае ошиби на стеке 0 и код ошибки.
Если успех -- на дескриптор открытого файла

Вопрос, к Хищнику -- можно иллюстрацию к плакату? :-)

ygrek

AlexF писал(а):

Поддерживаю in4. Скажем, в Перле это делается довольно просто:

Код:

open F, 'Data.txt' or warn "Can't open file: $!\n";

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

Исключение бросает не FILE-OPEN, а THROW который вы можете и не выполнять если вам так хочется! Т.е. никто не запрещает реализовать любое поведение, подсовывать пустой файл например.
Не пойму в чём проблема. Если вы хотите реагировать на ошибку в каком-то конкретном слове - вы должны из общих логических соображений (ОЛС) каким-то образом проанализировать успешность работы этого слова. Тут без вариантов. Это могут быть исключения, или код возвратов, или ещё что-нибудь, неважно, но какие-то действия от программиста требуются.

AlexF

Проблемы нет, есть предложение.

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

WingLion

AlexF писал(а):

В случае ошиби на стеке 0 и код ошибки.
Если успех -- на дескриптор открытого файла

Imho, Надо бы так:
После выполнения слов OpenFile и CreateFile
( -->ErrorCode, FALSE) - в случае ошибки
( --> FileHandle, TRUE) - в случае успеха

После выполнения ReadFile, WriteFile:
( --> ErrorCode, FALSE) - в случае ошибки
( --> Real_Len, TRUE) - в случае успеха
(Real_Len - реальная длина считанных/записанных данных)

Тогда, обработка ошибки выльется в обычный
IF с анализом флага и выдачей соответствующего сообщения,
Если же обработку ошибки в программе надо пропустить - делать простoй DROP флага.

Hishnik

AlexF писал(а):

Вопрос, к Хищнику -- можно иллюстрацию к плакату? Smile

/me накарябал иллюстрацию :writer;

Код:

: MY_HANDLER  ." Error opening file" ABORT ;

...

['] MY_HANDLER TO ERROR_OPENING

OPEN  \ слово само вызовет MY_HANDLER

in4

Хорошее качество исключений - упрощение исходника.
Пишешь, о сложностях не думая, где-то да поймается!

А вот как это правильно ловить? Хотя бы где?
На некоторые вопросы IMHO должна отвечать операционка, а не программа. С теми же повторениями и выбором другого файла.

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

Если это повесить на программу, та получится сложнее.

А как сделать так, чтобы переносить уровни отката (2-3, 5 слов откатываем) и принятия решений об откате еще в исходнике?
Т.е надо перенести, скажем, обработку ошибки открытия файла из слова, где файл непосредственно открывается, в слово, которое его вызывает...
Это надо с деревом разбора исходника работать?
Или простого THROW хватит?

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

Мне почему-то кажется, что логика обработки ошибок - это как еще одна программа, сопрограмма основного алгоритма работы,
которая может даже управлять выполнением этого основного алгоритма...
Интересно, так хватит к-нибудь конечного автомата?
И как бы их так разделить, чтобы можно было такой обработчик ошибок повторно использовать? Ведь программ похожих мнооого!

Hishnik

in4 писал(а):

Мне почему-то кажется, что логика обработки ошибок - это как еще одна программа, сопрограмма основного алгоритма работы,
которая может даже управлять выполнением этого основного алгоритма...

Именно!!! А THROW навязывает одну-единственную логику...

in4

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

Увеличивается сложность, затрудняется понимание и работа с исходником, больше мест для ошибок, сложнее и дольше отладка...

Или как Мур, плюнуть на все и просто сбрасывать всю систему и запускать поновой сначала. Программирование-то упрощается...
Но, если алгоритм долгий, начинать с самого начала- не очень приятное решение...

in4

Хищник писал(а):

А THROW навязывает одну-единственную логику...

Да, отмечаешь точки, откуда переход(на обработчик

) и нужно правильно распределить такие обработчики по иерархии вызовов...
Хорошо, если такое дерево не очень сложное...
Кстати, IMHO обработчики так никто как следует и не проектирует!

И тебе, Хищник, проще! У тебя железо под рукой - надо доп. конечный автомат для обработчика - пожалуйста, это много места не займет!

Ууу, а м.б. так и писать обработку ошибок - как сопрограмму?
Встроить слова для откатов на нужное место...
Такого я еще нигде не видел!

А получается красиво...

Уже и несколько вариантов реализации в голове закрутилось...

Как обрабатывать исключительные ситуации?

Кто сейчас на конференции