Здравствуйте, Владек, Вы писали:
В>Например, в текстовом редакторе вы переводите каретку на строку вверх. Допустим, этим занимается отдельный метод, который возвращает номер новой текущей строки. А строчка вверху короче и поэтому каретка также будет смещена по колонкам. В этом случае метод бросает исключение, в котором содержатся новые координаты каретки.
В>То есть, мы хотели изменить Y-координату каретки, но также изменилась и X-координата — это не ошибка, это исключительная ситуация.
Это называется строить логику работы приложения на исключениях. Я даже не знаю что хуже, использовать коды возврата или вот так на лево и на право швыряться исключениями.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, reductor, Вы писали:
СГ>>А что здесь есть кто-то утверждающий полезность единственности точки выхода из процедуры?
R>Ничего не хочу сказать ни про кого плохого, но я возьмусь утверждать, что несколько точек выхода — это хуже, чем один. R>Во всех случаях, когда этого можно избежать.
Почему? Можно аргументировать?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
В>>То есть, мы хотели изменить Y-координату каретки, но также изменилась и X-координата — это не ошибка, это исключительная ситуация.
IT>Это называется строить логику работы приложения на исключениях. Я даже не знаю что хуже, использовать коды возврата или вот так на лево и на право швыряться исключениями.
Если налево или направо, то, разумеется, исключения гораздо хуже.
А если в одном-двух местах и одним-двумя исключениями, то может быть и лучше.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Если налево или направо, то, разумеется, исключения гораздо хуже. E>А если в одном-двух местах и одним-двумя исключениями, то может быть и лучше.
Возвращаясь к исходному примеру, верхняя строчка будет короче в половине случаев, какое же это исключение?
Использовать исключения не для обработки ошибок — это совершенно исключительная ситуация, должна продумываться и документироваться очень тщательно.
Пример из буста: http://boost.org/libs/graph/doc/faq.html
# How do I perform an early exit from an algorithm such as BFS?
Create a visitor that throws an exception when you want to cut off the search, then put your call to breadth_first_search inside of an appropriate try/catch block. This strikes many programmers as a misuse of exceptions, however, much thought was put into the decision to have exceptions has the preferred way to exit early. See boost email discussions for more details.
Здравствуйте, reductor, Вы писали:
R>Ничего не хочу сказать ни про кого плохого, но я возьмусь утверждать, что несколько точек выхода — это хуже, чем один. R>Во всех случаях, когда этого можно избежать.
Избежать-то всегда можно. Вот и избегают некоторые фанатичные последователи этого правила, выходя из цикла 3-го уровня вложенности с помощью булевских флагов или даже бросая исключения .
Здравствуйте, Глеб Алексеев, Вы писали:
ГА>Избежать-то всегда можно. Вот и избегают некоторые фанатичные последователи этого правила, выходя из цикла 3-го уровня вложенности с помощью булевских флагов или даже бросая исключения .
Совершенно верно. Это правило было актуально 15 лет назад. Сегодня оно является таким же устаревшим как венгерка и SELECT*.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Глеб Алексеев, Вы писали:
ГА>Возвращаясь к исходному примеру, верхняя строчка будет короче в половине случаев, какое же это исключение?
ГА>Использовать исключения не для обработки ошибок — это совершенно исключительная ситуация, должна продумываться и документироваться очень тщательно.
Здравствуйте, eao197, Вы писали:
E>Ситуации, когда порождаются too_much_trx_t и repeated_trx_t -- это не ошибки, просто это исключительные ситуации для обычной обработки транзакций. Случаются они редко.
Не ошибки ? Ну, в таком случае отказ записи файла из за недостаточности места тоже не ошибка, а "исключительная ситуация для обычной обработки" файлов.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Глеб Алексеев, Вы писали:
ГА>>Возвращаясь к исходному примеру, верхняя строчка будет короче в половине случаев, какое же это исключение?
ГА>>Использовать исключения не для обработки ошибок — это совершенно исключительная ситуация, должна продумываться и документироваться очень тщательно.
E>Не спорю. Но я здесь и сам примеры приводил: E>Re[18]: Что вы предлагаете на замену эксепшенов?
(это из реальной жизни, хотя и схематично, а не точно).
Пример с парсером вовсе не гипотетический. Более того, он еще давно имеет свое название в Computer Science — это Parser Combinators. Несколько ограниченный случай, но тем не менее, все равно очень мощное средство.
Вообще формально, ситуации, когда мы куда-то передаем объект для коллбека разных его функций в зависимости от результата и отлавливаем несколько исключений эквивалентны друг другу. Ну за исключением незначительных здесь технических подробностей реализации.
Вообще непонятно почему все так против использования иксепшенов для описания логики, когда в большинстве рассматриваемых тут языков это самый быстрый и простой способ эмуляции pattern matching (не знаю как это по-русски), (чего о тех же классах с коллбеками по ним не скажешь).
Здравствуйте, Глеб Алексеев, Вы писали:
ГА>Здравствуйте, reductor, Вы писали:
R>>Ничего не хочу сказать ни про кого плохого, но я возьмусь утверждать, что несколько точек выхода — это хуже, чем один. R>>Во всех случаях, когда этого можно избежать. ГА>Избежать-то всегда можно. Вот и избегают некоторые фанатичные последователи этого правила, выходя из цикла 3-го уровня вложенности с помощью булевских флагов или даже бросая исключения .
Да-да, исключения — это кошмар. Да и return — для слабаков. Лучше вычисляемое фортрановское GOTO.
Чтобы ни одна тварь не поняла, что происходит.
Если чуть серьезнее, то логика — это штука немного формальная. Желание джампнуть куда-нибудь (частным случаем чего кроме GOTO является и множественный return), и сделать поведение программы непредсказуемым, это не от большого понимания того, что сам делаешь.
А еще — это не религия и понятие "фанатизм" к ней не применимо. Люди или могут обосновать свой вывод и выбор или нет.
На всякий случай заранее и воизбежание бессмысленных еще на 500 сообщений флеймов на эту тему хочу сказать, что
а) осознаю в некоторых случаях необходимость того же GOTO (в очень низкоуровневом коде на, например, Си или коде на плохо спроектированном языке).
б) в подавляющем большинстве прикладных случаев, что я видел (а это много), множественный выход был обусловлен или раздолбайством и нежеланием думать и отвечать за то, что делаешь или плохим пониманием проблемы и соответственно жутким дизайном с расчетом на последующий рефакторинг.
Что не отменяет, еще раз повторюсь варианта, где это может потребоваться. Правда встречается такое очень редко.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Глеб Алексеев, Вы писали:
ГА>>Избежать-то всегда можно. Вот и избегают некоторые фанатичные последователи этого правила, выходя из цикла 3-го уровня вложенности с помощью булевских флагов или даже бросая исключения .
IT>Совершенно верно. Это правило было актуально 15 лет назад. Сегодня оно является таким же устаревшим как венгерка и SELECT*.
Устарело?
Что, разобрались с остановкой тьюринг-полного автомата?
научились писать после этого статические анализаторы, которые находят и предсказывают поведение GOTO и множественного return?
Вырастили поколение суперлюдей, которые в состоянии смотрететь и тут же понимать что происходит, разбивая это в уме на подвыражения?
Наконец, уже написали компиляторы нормально это разруливающие и процессоры, у которых нет оверхеда от этого?
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, reductor, Вы писали:
СГ>>>А что здесь есть кто-то утверждающий полезность единственности точки выхода из процедуры?
R>>Ничего не хочу сказать ни про кого плохого, но я возьмусь утверждать, что несколько точек выхода — это хуже, чем один. R>>Во всех случаях, когда этого можно избежать.
IT>Почему? Можно аргументировать?
Потому что эти вещи очень сложно или вообще не поддаются анализу.
Потому что усложняют отладку, багов при этом попрождая больше.
Сильно усложняют понимание того, что программа делает.
Компилятору такое сложно или вообще невозможно оптимизировать.
Здравствуйте, reductor, Вы писали:
IT>>Почему? Можно аргументировать?
R>Потому что эти вещи очень сложно или вообще не поддаются анализу. R>Потому что усложняют отладку, багов при этом попрождая больше. R>Сильно усложняют понимание того, что программа делает. R>Компилятору такое сложно или вообще невозможно оптимизировать.
Это ты не про плюсы случаем?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, reductor, Вы писали:
R>>Хочу ссылки, выкладки и доказательства.
IT>Во-первых, calm down, во-вторых, аргументы я попросил
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, reductor, Вы писали:
IT>>>Почему? Можно аргументировать?
R>>Потому что эти вещи очень сложно или вообще не поддаются анализу. R>>Потому что усложняют отладку, багов при этом попрождая больше. R>>Сильно усложняют понимание того, что программа делает. R>>Компилятору такое сложно или вообще невозможно оптимизировать.
IT>Это ты не про плюсы случаем?
Здравствуйте, Sergey J. A., Вы писали:
SJA>Не ошибки ? Ну, в таком случае отказ записи файла из за недостаточности места тоже не ошибка, а "исключительная ситуация для обычной обработки" файлов.
В некоторых ситуациях это может быть совсем не ошибка. Например, в системах со сборкой мусора недостаток памяти для размещения нового объекта -- это еще не ошибка, а повод к запуску GC. И только если после работы GC памяти не окажется, то это становится ошибкой.
Так же и с файлами.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
reductor wrote:
> Если чуть серьезнее, то логика — это штука немного формальная. Желание > джампнуть куда-нибудь (частным случаем чего кроме GOTO является и > множественный return), и сделать поведение программы непредсказуемым, > это не от большого понимания того, что сам делаешь. > А еще — это не религия и понятие "фанатизм" к ней не применимо. Люди > или могут обосновать свой вывод и выбор или нет.
Нет, это уже религия. Все нормальные программисты уже давно перестали
флеймить по поводу GOTO и структурного программирования, так как по
нынешним меркам это уже далеко не самый главный вопрос. Все
программисты, которых я знаю, думают примерно так: "GOTO это плохо?" —
"Плохо". "Структурное программирование хорошо?" — "Да". "Единый return,
выход из вложенных циклов по флагам, отсутствие break — оно надо?" — "А
нафига?"
Здравствуйте, eao197, Вы писали:
E>В некоторых ситуациях это может быть совсем не ошибка. Например, в системах со сборкой мусора недостаток памяти для размещения нового объекта -- это еще не ошибка, а повод к запуску GC.
Именно. Это не ошибка, а часть алгоритма. Совершенно точно извесно как она будет обрабатыватся, причём самим сборщиком мусора. Поэтому нет никакой нужды передавать эту ситуацию в верхние уровни. Следовательно это и не должно считатся исключительной ситуацией и не должно вызывать исключение.
E> И только если после работы GC памяти не окажется, то это становится ошибкой.
Да, эта исключительная ситуация, и должна порождать исключение, что-бы верхние уровни (тут неизвесно кто конкретно) могли принять какое-либо решение — убить программу, сохранить дамп, спросить пользователя ...
E>Так же и с файлами.
Что то-же ? Не совсем понял...
С файлами представляю это так:
Если нет места на диске, но алгоритм расчитан так, что ищет место на других дисках и пробует сохранится туда — исключение не требуется (всё обрабатывается на одном уровне). Если уже нигде места нет — бросаем исключение — пусть кто знает обрабатывает.
Отсюда моё ИМХО: Исключение нужно бросать в том случае, если на данном логическом уровне (в данном модуле) неизвестен алгоритм работы с некоторой ситуацией. Которая и является исключительной на данном уровне.
На самом деле, применительно к доводам использования exception используется другое разделение:
1. Ошибка обрабатывается там же обнаруживается, или есть возможность построить иерархию обслуживания ошибочных ситуаций
2. в случае обработки ошибки прямо в месте обнаружения, так же анализируется возможность игнорирования ошибки, структурирование программы (if после каждой строки неудобен), ожидаемая частота ошибочных ситуаций (т.е. является ли ситуация "штатной" или действительно исключительной).
3. Кодами ошибок очень трудно централизовано управлять (знаю о чем говорю, науправлялись достаточно кодом HRESULT в COM-системе из около 50 проектов), иерархии исключений могут быть совершенно независимы или наоборот, зависимы при необходимости.
Если нам не помогут, то мы тоже никого не пощадим.
ситуация, должна продумываться и документироваться очень тщательно. 
.
