Нужна ли в языке обработка исключений?

Илья Ермаков

Вот и сделайте для вашей задачи такой слой абстракции. Пусть ошибки обрабатываются "в трюмах" и выходят наверх только в "командирскую рубку" (некоторый диспетчерский код приложения), а пассажиры на палубе (основная логика) про них вообще не подозревают....
Ну а уж если корабль разломился пополам (ошибка в самой программе), то что толку кричать об этом пассажирам (генерировать исключение вверх по стеку вызовов) - надо кидать кого можно в шлюпки (спасать данные) и перевозить на новый корабль (перезапускать приложение).

CheshireCat

Geniepro писал(а):

Пресловутая правильность оберон-технологии тоже требует цены, и немалой.

по сравнению с тоооолстым Хаскелем - малой))

Geniepro писал(а):

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

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

Info21

CheshireCat писал(а):

... реиспользование означает зависимость.
в зависимостях надо знать меру.

Очень good point. (Geniepro знает по-американски, поэтому не перевожу.)

CheshireCat писал(а):

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

Наш человек! В смысле, Информатики-21 :-)

Илья Ермаков

Читая материалы по метациклической машине Java Jikes RVM (поясню: метациклической они называют потому, что она полностью написана и "раскручивается" при старте на самой Java, в отличие от Оберона в мире Java это редкость, основные Java-машины написаны на С++)...

У них, естественно, идёт сразу компиляция в маш. код (интерпретации нет вообще) - при первом вызове метода, но простым и быстрым компилятором, далее специальный компонент сидит в памяти и следит за профилем вызовов и "узкими местами" и в рантайме запускает для нужных мест оптимизирующий компилятор. Оптимизирующий построен на трёх проходах, на каждом из которых что-то преобразуется, из представления в представление, всё ближе к маш. коду.

Так вот, неоднократно упомянут геморрой, который доставляет возможность исключений, даже для просто динамической компиляции, не говоря про оптимизацию. Exception хуже goto, потому что goto локален, а exeption может выстрелить из любого вызова. Это очень сильно стопорит оптимизацию, потому что всегда нужно быть готовым раскручивать исключение. Приходится применять всякие "фокусы".
Вот так вот.

Владислав Жаринов

Илья Ермаков писал(а):

...
Exception хуже goto, потому что goto локален, а exeption может выстрелить из любого вызова. Это очень сильно стопорит оптимизацию, потому что всегда нужно быть готовым раскручивать исключение. Приходится применять всякие "фокусы".
Вот так вот.

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

Александр Шостак

Считал и считаю исключения аналогом goto, привязанном к тому же к данным.

Сергей Губанов

Илья Ермаков писал(а):

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

Для Явы это странно...

Вот для С++ это беда. Там гарантируется что в случае исключения деструкторы локальных объектов всё равно будут вызваны (а значит каждый блок содержащий такие объекты должен неявно быть обёрнут в try-finally обёртку).

Для Питона это тоже беда. Там для локальных объектов надо выполнить decrement count (иначе память утечёт) в любом случае, даже если произошло исключение.

В Дельфях, кстати, для строк и интерфейсных переменных тоже управляемых по счётчику ссылок это тоже беда.

Но в Яве же настоящий сборщик мусора и локальных объектов с деструкторами как в С++ там нет, так что странно что они жалуются...

Владислав Жаринов

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

Илья Ермаков в viewtopic.php?f=2&t=3552#p64914 писал(а):

Обычный if с генерацией исключения ОС.

- получаем, что нужно два диалекта языка. Один - для прикладного программирования - будет иметь сверх средств описания обычной маршрутной логики (с единственным "главным финишем" или без такового) только assert (под которым понимается if с выходом по нарушению пароля охраны инварианта). Другой - для системного программирования - будет содержать возможности обработки выходов из assert-if (возникающих в несистемных программах... а м.б. и в каких-то системных?) по нарушению пароля.
Тут как раз и вопрос - как этот выход должен выглядеть? И со стороны прикладного диалекта - просто как БП внутрь ОС? как возвратный БП на какую-то сообразную контексту выхода ОС-процедуру (в которую входим)? И как со стороны системного диалекта?
Или это как-то не так в целом решаться должно?

Александр Шостак

Можно по условию делать вызов определённой процедуры (а не генерацию исключения), в ней проверять источник проблемы: если прикладные модули, то диагностика, иначе завершение.

Владислав Жаринов

Это уже какая-то определённость... а завершение этой процедуры, очевидно, подразумевает останов?

Валерий Лаптев

Мой опыт показывает, что обработку ошибок нужно проектировать точно так же, как и основную реализацию.
И в зависимости от проекта применять уже те или иные адекватные инструменты для реализации. Это может быть отдельная библиотека, например.
Пока мне механизм обработки исключений, в том виде, в каком он в С++ (и в последующих) - не сильно нравится. Слишком уж этот механизм (как и все в С++) - свободен от ограничений. А так - не должно быть.
В этом смысле контракты в Эйфеле - гораздо лучше. Именно к нарушению контрактов надо привязывать обработку ошибок. А в каком виде - это уже думать надо.

Владислав Жаринов

Вот тут ещё мнение: http://www.novosti-kosmonavtiki.ru/phpB ... 653#848653

Валерий Лаптев

Пот с этим полностью согласен:

Цитата:

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

То есть в самом языке должны быть средства, которые программист должен ВСЕГДА писать в нужном месте. Контракты Эйфеля - это только самое начало, что нужно писать обязательно. А вообще, как я говорил - нужно проектировать алгоритмы обработки ошибок. И в программе прописывать их в обязательном порядке в соответствующих местах.
Например, функция имеет тело для нормальной обработки и тело для обработки ненормальной. И это в языке - некая конструкция. И никаких умолчаний.

Info21

Валерий Лаптев писал(а):

Например, функция имеет тело для нормальной обработки и тело для обработки ненормальной. И это в языке - некая конструкция. И никаких умолчаний.

Но тело для обработки можно также не заполнить.

И в итоге это не дает ничего по сравнению с обычной логикой проверок и кодов возврата.

Евгений Темиргалеев

Валерий Лаптев писал(а):

Например, функция имеет тело для нормальной обработки и тело для обработки ненормальной. И это в языке - некая конструкция. И никаких умолчаний.

А не окажется эта конструкция городухой, синтаксически подобной обработке исключений?

Ниже пример процедуры, выдающей коды ошибк. Перерисуйте при помощи гипотетической конструкции, сравним.

Код:

PROCEDURE SetFileTime (IN fname: ARRAY OF SHORTCHAR; IN date: Dates.Date; IN time: Dates.Time; OUT result: INTEGER);
      VAR
         code, res: INTEGER;
         stat: Libc.stat_t;
         newTime: Libc.tmDesc;
         newTimes: Libc.utimbuf;
   BEGIN
      ASSERT(Dates.ValidDate(date), 20);
      ASSERT(Dates.ValidTime(time), 21);
      code := 0;
      Stat(fname, stat, res); ASSERT((res = 0) OR (res = -1), 100);
      IF res # 0 THEN
         code := 1   (* не получены атрибуты *)
      END;
      IF code = 0 THEN
         newTimes.actime := stat.st_atime;
         newTime.tm_year := date.year - 1900;
         newTime.tm_mon := date.month - 1;
         newTime.tm_mday := date.day;
         newTime.tm_hour := time.hour;
         newTime.tm_min := time.minute;
         newTime.tm_sec := time.second;
         newTimes.modtime := Libc.timelocal(newTime);
         IF newTimes.modtime = -1 THEN
            code := 2   (* не сформировалось время *)
         END
      END;
      IF code = 0 THEN
         res := Libc.utime(fname, newTimes); ASSERT((res = 0) OR (res = -1), 101);
         IF res # 0 THEN
            code := 3   (* не установилось время *)
         END
      END;
      (* Конец *)
      result := code
   END SetFileTime;

Владислав Жаринов

А ещё интереснее - также перерисовать... скажем, в структурном редакторе...

Валерий Лаптев

Я к тому, что нужны конструкции, отличающиеся от обработки исключений. Это раз. И второе, ИМХО более важное - написание этих конструкций должно быть ОБЯЗАТЕЛЬНЫМ. И обработка исключений, и обработка кодов ошибок - не обязательны. Хочешь - пиши, не хочешь - не пиши.
Кстати, если "с молодости" писать правильно, то это становится привычкой. Мой студент, реализующий среду, это прямо подтвердил. Ему для проверки среды пришлось писать на реализуемом языке, а там - все только структурно. По-другому никак не дает среда. И он сказал, что и на Сишарпе стал писать гораздо более правильно, чем раньше. А главное, ему стало так писать удобнее. И программы получаются проще, понятнее.
"Качество - дело привычки"(с). Только эту привычку надо "вбивать с молодости" - в обязательном порядке, а не словами-уговорами.

Евгений Темиргалеев

Валерий Лаптев писал(а):

Я к тому, что нужны конструкции, отличающиеся от обработки исключений. Это раз. И второе, ИМХО более важное - написание этих конструкций должно быть ОБЯЗАТЕЛЬНЫМ. И обработка исключений, и обработка кодов ошибок - не обязательны. Хочешь - пиши, не хочешь - не пиши.
...
"Качество - дело привычки"(с). Только эту привычку надо "вбивать с молодости" - в обязательном порядке, а не словами-уговорами.

Идея вроде понятна. Вы хотите вбивание переложить с преподавателя на язык. Но для этого последний нужно изменить. Сомнения как раз в том, что Ваша цель разумно достижима на уровне синтаксиса/семантики языка.

Alexey_Donskoy

Евгений Темиргалеев писал(а):

Сомнения как раз в том, что для Вашей цели это возможно разумными средствами.

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

Сергей Прохоренко

Валерий Лаптев писал(а):

Я к тому, что нужны конструкции, отличающиеся от обработки исключений. Это раз. И второе, ИМХО более важное - написание этих конструкций должно быть ОБЯЗАТЕЛЬНЫМ. И обработка исключений, и обработка кодов ошибок - не обязательны. Хочешь - пиши, не хочешь - не пиши.
Кстати, если "с молодости" писать правильно, то это становится привычкой. Мой студент, реализующий среду, это прямо подтвердил. Ему для проверки среды пришлось писать на реализуемом языке, а там - все только структурно. По-другому никак не дает среда. И он сказал, что и на Сишарпе стал писать гораздо более правильно, чем раньше. А главное, ему стало так писать удобнее. И программы получаются проще, понятнее.
"Качество - дело привычки"(с). Только эту привычку надо "вбивать с молодости" - в обязательном порядке, а не словами-уговорами.

Полностью присоединяюсь!

Вот мой вариант генерации и обработки исключений нового типа в процедуре Евгения Темиргалеева:

Код:

PROCEDURE SetFileTime (IN fname: ARRAY OF SHORTCHAR; IN date: Dates.Date; IN time: Dates.Time);
    VAR
        stat: Libc.stat_t;
        newTime: Libc.tmDesc;
        newTimes: Libc.utimbuf;
    BEGIN
        IF NOT Dates.ValidDate(date) THEN ESCAPE(NotValidDate)
        ELSIF NOT Dates.ValidTime(time) THEN ESCAPE(NotValidTime) END;
        Stat(fname, stat, res);
        IF NOT ((res = 0) OR (res = -1)) THEN ESCAPE(BadStat)
        ELSIF (res = -1) THEN ESCAPE(NotGotAttributes) END; (* не получены атрибуты *)
        newTimes.actime := stat.st_atime;
        newTime.tm_year := date.year - 1900;
        newTime.tm_mon := date.month - 1;
        newTime.tm_mday := date.day;
        newTime.tm_hour := time.hour;
        newTime.tm_min := time.minute;
        newTime.tm_sec := time.second;
        newTimes.modtime := Libc.timelocal(newTime);
        IF newTimes.modtime = -1 THEN ESCAPE(NotModTime) END; (* не сформировалось время *)
        res := Libc.utime(fname, newTimes);
        IF NOT ((res = 0) OR (res = -1)) THEN ESCAPE(BadNewTimes) 
        ELSIF res # 0 THEN ESCAPE(NotSetTime) END; (* не установилось время *)
END SetFileTime;


CALL SetFileTime (the_fname; the_date; the_time); (* вызов процедуры и обработка "исключений нового типа" *)
    CATCH(NotValidDate) …;
    CATCH(NotValidTime) …;
    CATCH(BadStat) …;
    CATCH(NotGotAttributes) …;
    CATCH(NotModTime) …;
    CATCH(BadNewTimes) …;
    CATCH(NotSetTime) …;

Ветки CATCH должны появляться автоматически при попытке указать вызов процедуры.
Разумеется, в структурном редакторе можно обойтись без лишниего текстового мусора, используя графику по шаблону:

Вложение:

exception.png [ 24.11 КБ | Просмотров: 15001 ]

OberonCore

Нужна ли в языке обработка исключений?

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