NC>А вот очень бы хотелось услышать, что вы предлагаете на замену эксепшенов, только мб в новой теме. Они много чем не нравятся, но пока не видно лучших механизмов обработки ошибок.
Я делю ошибки на две категории:
1) ошибки в данных (программа на вход получила неправильные данные);
2) ошибки в программе (программист ошибся: а) просто ошибся; б) сложно ошибся — в дизайне/архитектуре).
Ошибки категори (1) легко обрабатывается без механизма exceptions, так надо проектировать просто.
Ошибки категории (2) фатальные, тут программу надо завершать — в программе ошибка, т.е. программа не правильная. Использовать exception только для того чтобы правильно завершить работу программы (ну там закрыть открытые ресурсы), только для этого чтоли? Закрыть открытое можно и другими способами.
> > NC>А вот очень бы хотелось услышать, что вы предлагаете на замену эксепшенов, только мб в новой теме. Они много чем не нравятся, но пока не видно лучших механизмов обработки ошибок. > > Я делю ошибки на две категории: > 1) ошибки в данных (программа на вход получила неправильные данные); > 2) ошибки в программе (программист ошибся: а) просто ошибся; б) сложно ошибся — в дизайне/архитектуре). > > Ошибки категори (1) легко обрабатывается без механизма exceptions, так надо проектировать просто.
Как именно? Затруднения возникают с тем, что ошибка диагностируется на нижнем уровне, а обрабатываться обычно должна на верхнем. В случае использования, скажем, кодов возврата вводится зависимость от нижних уровней во все промежуточные.
> Использовать exception только для того чтобы правильно завершить работу программы (ну там закрыть открытые ресурсы), только для этого чтоли?
Исключения в первую очередь предназначены именно для (1).
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Ошибки категори (1) легко обрабатывается без механизма exceptions, так надо проектировать просто. СГ>Ошибки категории (2) фатальные, тут программу надо завершать — в программе ошибка, т.е. программа не правильная. Использовать exception только для того чтобы правильно завершить работу программы (ну там закрыть открытые ресурсы), только для этого чтоли? Закрыть открытое можно и другими способами.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Я делю ошибки на две категории: СГ>1) ошибки в данных (программа на вход получила неправильные данные); СГ>2) ошибки в программе (программист ошибся: а) просто ошибся; б) сложно ошибся — в дизайне/архитектуре).
СГ>Ошибки категори (1) легко обрабатывается без механизма exceptions, так надо проектировать просто.
Писать функции, возвращающие код ошибки? Иногда так и стоит делать, но за правило я бы это ни в коем случае не брал.
СГ>Ошибки категории (2) фатальные, тут программу надо завершать — в программе ошибка, т.е. программа не правильная. Использовать exception только для того чтобы правильно завершить работу программы (ну там закрыть открытые ресурсы), только для этого чтоли? Закрыть открытое можно и другими способами.
Не согласен с выделенным, это относится только к определенному классу приложений. Например, разрабатывая расширяемую плагинами систему, не будешь же ты полататься на непогрешимость сторонних разработчиков?
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Ошибки категори (1) легко обрабатывается без механизма exceptions, так надо проектировать просто.
Это при помощи кодов ошибок? Есть один момент, принципиально отличающий коды ошибок от исключений. Чтобы проигнорировать код ошибки, ничего делать не нужно, именно поэтому в реальных ситуациях они часто и игнорируются. А вот чтобы проигнорировать исключение, нужны явные действия по их игнорированию. Плюс разнесение логики генерации и обработки ошибок на разные уровни без задействования промежуточных.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, psg, Вы писали:
psg>>А собственно, чем вам не нравятся exceptions?...
IT>Видимо они отсутствуют в Обероне.
NC>>А вот очень бы хотелось услышать, что вы предлагаете на замену эксепшенов, только мб в новой теме. Они много чем не нравятся, но пока не видно лучших механизмов обработки ошибок.
СГ>Я делю ошибки на две категории: СГ>1) ошибки в данных (программа на вход получила неправильные данные); СГ>2) ошибки в программе (программист ошибся: а) просто ошибся; б) сложно ошибся — в дизайне/архитектуре).
СГ>Ошибки категори (1) легко обрабатывается без механизма exceptions, так надо проектировать просто. СГ>Ошибки категории (2) фатальные, тут программу надо завершать — в программе ошибка, т.е. программа не правильная. Использовать exception только для того чтобы правильно завершить работу программы (ну там закрыть открытые ресурсы), только для этого чтоли? Закрыть открытое можно и другими способами.
Посыл неверный.
Пример: некий оффлайн клиент. Пользователь отредактировал документ и хочет его скинуть на сервер. Сервер недоступен. Какая это ошибка в вашей терминологии? На 1ую непохоже, а во втором случае надо завершить программу? И все, что было создано пропадет?
Аналогично с сохранением файла на носитель, на котором кончилось место. По идее надо дать возможность сменить носитель и т.д., а не молча закрыть прогу.
Опять возвращаемся к кодам ошибок или исключениям.
NC>>А вот очень бы хотелось услышать, что вы предлагаете на замену эксепшенов, только мб в новой теме. Они много чем не нравятся, но пока не видно лучших механизмов обработки ошибок.
СГ>Я делю ошибки на две категории: СГ>1) ошибки в данных (программа на вход получила неправильные данные); СГ>2) ошибки в программе (программист ошибся: а) просто ошибся; б) сложно ошибся — в дизайне/архитектуре).
Ключевой момент -- это большое и жирное "Я" в твоем утверждении.
А вообще, кроме классика Н.Вирта, есть еще и классик Б.Страуструп. В его книге "Язык программирования С++. 3-е издание" есть целая глава #14, которая посвящена обработке исключений. Тебе бы не мешало прочитать из нее хотя бы 14.1 (Обработка ошибок [except.error]) и 14.1.1 (Альтернативный взгляд на исключения [except.views]). Там очень сжато и точно описываются разные стратегии диагностики ошибок и роль в этом деле исключений.
Note. Названия разделов я привел из англиского варианта книги, т.к. русский вариант у меня на работе.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
NC>>А вот очень бы хотелось услышать, что вы предлагаете на замену эксепшенов, только мб в новой теме. Они много чем не нравятся, но пока не видно лучших механизмов обработки ошибок.
СГ>Я делю ошибки на две категории: СГ>1) ошибки в данных (программа на вход получила неправильные данные); СГ>2) ошибки в программе (программист ошибся: а) просто ошибся; б) сложно ошибся — в дизайне/архитектуре).
СГ>Ошибки категори (1) легко обрабатывается без механизма exceptions, так надо проектировать просто.
Смысл исключений — увеличить скорость работы. Вместо постоянных лишних проверок вводится иной механизм, отнимающий время лишь в исключительных случаях. Механизм настолько важен, что обычно реализуется аппаратно процессором. Например, механизм подкачки (paging) в современных ОС реализован именно на аппаратных исключениях. По-другому его сделать так эффективно нереально. В силу существования аппаратного механизма, большенство компилируемых языков его используют и для высокоуровневых исключений.
СГ>Ошибки категории (2) фатальные, тут программу надо завершать — в программе ошибка, т.е. программа не правильная. Использовать exception только для того чтобы правильно завершить работу программы (ну там закрыть открытые ресурсы), только для этого чтоли? Закрыть открытое можно и другими способами.
Может быть и можно, но в системах использующих аппаратные механизмы защиты — это наиболее простой (а не только быстрый) способ.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
NC>>>А вот очень бы хотелось услышать, что вы предлагаете на замену эксепшенов, только мб в новой теме. Они много чем не нравятся, но пока не видно лучших механизмов обработки ошибок.
СГ>>Я делю ошибки на две категории: СГ>>1) ошибки в данных (программа на вход получила неправильные данные); СГ>>2) ошибки в программе (программист ошибся: а) просто ошибся; б) сложно ошибся — в дизайне/архитектуре).
E>Ключевой момент -- это большое и жирное "Я" в твоем утверждении.
E>А вообще, кроме классика Н.Вирта, есть еще и классик Б.Страуструп. В его книге "Язык программирования С++. 3-е издание" есть целая глава #14, которая посвящена обработке исключений. Тебе бы не мешало прочитать из нее хотя бы 14.1 (Обработка ошибок [except.error]) и 14.1.1 (Альтернативный взгляд на исключения [except.views]). Там очень сжато и точно описываются разные стратегии диагностики ошибок и роль в этом деле исключений. E>Note. Названия разделов я привел из англиского варианта книги, т.к. русский вариант у меня на работе.
Ещё есть один классик т.н. "контрактоного программирования" (кстати, последователь Н.Вирта, сейчас работает в ETH) — Бертран Мейер, автор языка Eiffel.
Стоит почитать и его.
Здравствуйте, iZEN, Вы писали:
E>>А вообще, кроме классика Н.Вирта, есть еще и классик Б.Страуструп. В его книге "Язык программирования С++. 3-е издание" есть целая глава #14, которая посвящена обработке исключений. Тебе бы не мешало прочитать из нее хотя бы 14.1 (Обработка ошибок [except.error]) и 14.1.1 (Альтернативный взгляд на исключения [except.views]). Там очень сжато и точно описываются разные стратегии диагностики ошибок и роль в этом деле исключений. E>>Note. Названия разделов я привел из англиского варианта книги, т.к. русский вариант у меня на работе.
ZEN>Ещё есть один классик т.н. "контрактоного программирования" (кстати, последователь Н.Вирта, сейчас работает в ETH) — Бертран Мейер, автор языка Eiffel. ZEN>Стоит почитать и его.
Стоит, безусловно. А что именно? Если можно URL, т.к. у нас достать печатное издание крайне проблематично.
Я упомянул разделы 14.1 и 14.1.1 книги Страуструпа потому, что там описываются следующие стратегии поведения в случае возникновения ошибок:
аварийное завершение программы;
возврат значения, определяющего наличие ошибки;
возврат корректного значения, но оставление программы в некорректном состоянии;
вызов специально предоставленных функций для реакции на ошибки
и приводится сравнение этих вариантов с вариантом использования исключений.
Во многих случаях в C++ (да и не только), исключения являются единственным способом информирования приложения об ошибках. Например, при перегрузке операторов. Например, оператора << или +. На самом деле, как использовать коды ошибок вот в таком выражении:
db_stream << header << description << footer;
а ошибка возникает из-за отсутствия достаточного места на диске?
Ну и еще одно соображение. Исключения, в отличии от того же контрактного программирования, стали широко призанным и адаптированным механизмом. C++, Java, C#, Python, Ruby, Ada, Smalltalk -- везде есть исключения. Конечно, это не панацея от всех болезней, и применять их нужно осторожно. Тем не менее, вряд ли идея исключений получила бы такое широкое распространение, если бы она не была настолько удачной.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
например, обработка через continuation passing — см. например, conditions в Common Lisp. И этот подход, нужно сказать, кроме того, что быстрее, чем иксепшены, еще и дает возможность поправить ошибку на месте — без раскрутки стека — и продолжить делать то же самое как ни в чем не бывало.
Так же, в строго-типизированых языках это могут контейнерные (higher order aka kinds) типы
еще довольно уникальный случай — в хаскеле некоторые библиотечные типы для обработки ошибок определены еще и как монады. например, Maybe. Хотя некоторые виды ошибок в хаскеле по-умолчанию предлагается отлавливать через некоторую симуляцию иксепшенов, которая впрочем чистой воды те же continuations + контейнерные типы.
Здравствуйте, psg, Вы писали:
psg>Здравствуйте, IT, Вы писали:
IT>>Здравствуйте, psg, Вы писали:
psg>>>А собственно, чем вам не нравятся exceptions?...
IT>>Видимо они отсутствуют в Обероне.
psg>Это не повод, в обероне много что отсутствует
А кто сказал, что не нравятся только exceptions?...
Я не собираюсь предлагать что-то вместо эксепшн, но вот идею их я бы расширил. Сейчас — это просто уведомление о чем-то. Я бы добавил в них возможность исправления, если, конечно, возможно.
Происходит исключение. Выбрасывется экземпляр класса исключения. Это экземпляр получает доступ к классу/методу, где произошло исключение, анализирует причину и изменяет состояние класса, после чего, возможно, повторяет операцию, вызвавшую исключение.
Я бы называл это "теневой обработкой исключений"
При этом мы будем иметь "автоматизированную обработку исключений" — можно будет писать код, который в самом исключении пытается исправить ситуацию. Можно будет писать код, который не будет содержать try-catch. Просто если этот код выбросит исключение, то экземпляр исключения появится сам, исправит что надо и сам же исчезнет.
Разумеется, это не везде и всегда возможно. Поэтому если не может исправить — перевыбрасывает исключение на более высокий уровень.
В свое время такое в примитивном виде было в Фортране IBM/360. Там можно было задать "корректирующее действие". Например, при переполнении стандартное корректирующее действие заключалось в засылке MAXFLOAT в ячейку ответа. Т.е. происходило "исключение" (ovarflow в процессоре), автоматом запускался некий код, который и обрабатывал это исключение, так что я даже не знал, что оно произошло. Можно было задать свое действие.
Понимаю, что технических проблем здесь хватит, и вряд ли нынешние языки это потянут, но самам идея, ИМХО, имеет право на существование.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я не собираюсь предлагать что-то вместо эксепшн, но вот идею их я бы расширил. Сейчас — это просто уведомление о чем-то. Я бы добавил в них возможность исправления, если, конечно, возможно.
PD>Происходит исключение. Выбрасывется экземпляр класса исключения. Это экземпляр получает доступ к классу/методу, где произошло исключение, анализирует причину и изменяет состояние класса, после чего, возможно, повторяет операцию, вызвавшую исключение. PD>Я бы называл это "теневой обработкой исключений"
Это так называемые "продолжаемые исключения". Работает в языках, не разрушающих стек во время поиска обработчика. Например в ST, CLOS.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Использовать exception только для того чтобы правильно завершить работу программы (ну там закрыть открытые ресурсы), только для этого чтоли? Закрыть открытое можно и другими способами.
afaik, так Erlang работает — тред с исключением прибивается. Нормальная система, имхо.
Если нам не помогут, то мы тоже никого не пощадим.
