Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 53
Насколько понимаю, эту самую мысль доводил Страуструп чуть ли не с самой первой своей книги!
Насколько я понимаю механизм исключений появился не просто как средство сказать об ошибки, а скорее как средство принуждающего программиста-пользователя обработать ошибку! Ведь всем известно, что если функция возвращает значение какого-нить типа, то это еще не говорит что это значение обязательно проверят! А так хотя бы безусловный catch(...) поставят, что будет говорить о том, что программист хоть немного но осведомлено об ошибке!
В C++ всё-таки механизм исключений, к сожалению, не слишком-то располагает программиста к использованию исключений, в отличии от, например, Java. Всё дело в том, что в Java есть такая вещь как проверяемые исключения.
Не писал на Java и ничего не скажу про нее. Но если не обработать исключение в коде на С++, то пользователь точно заметит. Вернее с определенной вероятностью в 99%
Проверяемые исключения — полубесполезная вещь.
Все дело в java.lang.RuntimeException от которого наследуется большое число важный исключений, которые в итоге не проверяются. В итоге да, какую-то часть ошибок нас заставят проверить, но RuntimeException это такая дырка, через которую обязательно пролезет что-то лишнее, что обязательно нужно было проверить.
Не нужно было делать java.lang.RuntimeException непроверяемым или хотя бы запретить наследоваться от него не стандартным классам.
Все дело в java.lang.RuntimeException от которого наследуется большое число важный исключений, которые в итоге не проверяются. В итоге да, какую-то часть ошибок нас заставят проверить, но RuntimeException это такая дырка, через которую обязательно пролезет что-то лишнее, что обязательно нужно было проверить.
Не нужно было делать java.lang.RuntimeException непроверяемым или хотя бы запретить наследоваться от него не стандартным классам.
Если бы все исключения были бы проверяемыми, Вам пришлось бы проверять во всем коде NPE, деление на ноль, передачу неверных параметров и т.д., даже там, где заведомо известно, что этого не может быть.
Checked exceptions в JVM используются для того, чтобы сигнализировать об ошибках, возникновение которых мы не можем контролировать. В частности, ошибки ввода/вывода. И это не панацея.
Checked exceptions в JVM используются для того, чтобы сигнализировать об ошибках, возникновение которых мы не можем контролировать. В частности, ошибки ввода/вывода. И это не панацея.
Совершенно верно. Выброс непроверяемого исключения говорит о некорректной работе метода, либо некорректном его вызове (недопустимые параметры). И это является ошибкой программы, а не исключительной ситуацией, и решается элементарным тестированием.
Еще есть такая штука как контрактное программирование (http://code.google.com/p/cofoja/). Оно позволяет жестче контролировать корректность вызовов методов и обнаруживать ошибки на ранних стадиях. Каждый метод содержит дескриптор, где указываются ожидаемые значения аргументов и результатов. Там же указываются ВСЕ ожидаемые исключения от метода, как checked, так и unchecked.
Кстати, в javadoc для java api также как правило указываются все unchecked exceptions, которые может выдать метод.
Еще есть такая штука как контрактное программирование (http://code.google.com/p/cofoja/). Оно позволяет жестче контролировать корректность вызовов методов и обнаруживать ошибки на ранних стадиях. Каждый метод содержит дескриптор, где указываются ожидаемые значения аргументов и результатов. Там же указываются ВСЕ ожидаемые исключения от метода, как checked, так и unchecked.
Кстати, в javadoc для java api также как правило указываются все unchecked exceptions, которые может выдать метод.
Насчет наследования от RuntimeException.
Если у вас есть единая точка обработки какого-то вашего исключения, будет очень утомительно во всех методах ваших классов прописывать выкидывание этого исключения.
А если возможных исключений порядка 5 (что бывает намного чаще, чем хотелось бы)? Все прописывать в сигнатуры методов? Это был бы громадный шаг к потере читаемости.
Если у вас есть единая точка обработки какого-то вашего исключения, будет очень утомительно во всех методах ваших классов прописывать выкидывание этого исключения.
А если возможных исключений порядка 5 (что бывает намного чаще, чем хотелось бы)? Все прописывать в сигнатуры методов? Это был бы громадный шаг к потере читаемости.
Вообще, catch(...), если посмотреть на него с другой стороны,
говорит не только о том, что программист осведомлен об ошибке, но и о том, что разработчик полностью
не владеет ситуацией и не знает о «типовых» для своего кода исключительных ситуаций, затыкая их catch(...).
Последнее, имхо, применимо в критических участках кода, в процессах, которые не должны никогда падать, а во всех других случаях можно допустить выход исключения в систему.
По крайней мере, его будет проще дебажить, общаться с удаленным клиентом тоже будет проще, особенно если сравнить со случаем, когда в try catch (...) мы имеем, не культурно обернутый exception, а сообщение «а х** его знает, что там у меня»
говорит не только о том, что программист осведомлен об ошибке, но и о том, что разработчик полностью
не владеет ситуацией и не знает о «типовых» для своего кода исключительных ситуаций, затыкая их catch(...).
Последнее, имхо, применимо в критических участках кода, в процессах, которые не должны никогда падать, а во всех других случаях можно допустить выход исключения в систему.
По крайней мере, его будет проще дебажить, общаться с удаленным клиентом тоже будет проще, особенно если сравнить со случаем, когда в try catch (...) мы имеем, не культурно обернутый exception, а сообщение «а х** его знает, что там у меня»
Ну в современном C++ коде почти все исключения все же наследуются от ::std::exception (не видел реальных примеров обратного), поэтому в среднестатистическом main-е большого проекта, использующего множество библиотек все же присутствует catch(exception& e). Перед ним может идти пару специфичных кетчей, но на деле все же именно этот общий будет ловить почти все ошибки, ибо так записывается логика «если вот такие ошибки, мы можем что то делать, в противном случае — записать в лог и умереть».
Так что catch(...) и catch(::std::exception&) это плохо только в теории, а так — иногда другого выхода просто нет.
Так что catch(...) и catch(::std::exception&) это плохо только в теории, а так — иногда другого выхода просто нет.
Ну да, это специфический инструмент, и спользовать его надо в соответствующих ситуациях. К примеру — top-level обработчик, который залогирует (возможно — сложным образом) состояние приложения, возможно — выйдет с осмысленным кодом ошибки. А возможно всё же попытается более-менее корректно освободить ресурсы перед смертью.
да, именно. в точку!
Эти размышления действительны для всех типов ошибок?
Я бы, наверное, назвал такие:
1)критические ошибки ресурсов/потов окружения {SIG_ABORT} или сбой чётности памяти, требуют остановить программу
2)некритические ошибки ресурсов/потоков, реакция варьируется между игнорированием, ожиданием, ветвлением/диалогом и пр.
3)ошибки аргументов к нашей функции, реакция зависит от контекста
4)ошибки аргументов к чужой функции {tan(PI/2)} реакция зависит от контекста
Я бы, наверное, назвал такие:
1)критические ошибки ресурсов/потов окружения {SIG_ABORT} или сбой чётности памяти, требуют остановить программу
2)некритические ошибки ресурсов/потоков, реакция варьируется между игнорированием, ожиданием, ветвлением/диалогом и пр.
3)ошибки аргументов к нашей функции, реакция зависит от контекста
4)ошибки аргументов к чужой функции {tan(PI/2)} реакция зависит от контекста
>Эти размышления действительны для всех типов ошибок?
В первом пункте — ошибки, которые вне модели runtime'а С++, поэтому на уровне С++ их не обработать (сбой чётности, например, — где гарантия, что наш код обработчика уже не испорчен?).
Остальные обрабатываются единообразно — либо на данном уровне ясно, что с ними делать, либо — неясно и решать будет предыдущий уровень.
В первом пункте — ошибки, которые вне модели runtime'а С++, поэтому на уровне С++ их не обработать (сбой чётности, например, — где гарантия, что наш код обработчика уже не испорчен?).
Остальные обрабатываются единообразно — либо на данном уровне ясно, что с ними делать, либо — неясно и решать будет предыдущий уровень.
Копайте в истории дальше. Задача возникла не там. Исключения — это всего лишь способ передать управления на несколько уровней вверх. Все. Обработка ошибок — это частный случай.
Использовать исключения для «очень удобного» выхода из функции — один из самых худших вариантов их использования.
ну в плюсах — да
Везде. И исключение по определению именно возникновение нештатной ситуации. Если проблема только в передаче на несколько уровней — фигня проблема, goto в подходящей инкарнации и все дела.
Я же и сказал — goto в подходящей инкарнации. НЕШТАТНАЯ СИТУАЦИЯ — ситуация, при которой технологический процесс или состояние оборудования выходит за рамки нормального функционирования и может привести к аварии (БСЭ). Исключение возбуждается, если ввиду какой-то причины нормальное, запланированное поведение программы (выполнение алгоритма) становится невозможным. Нехватка памяти — как раз такая ситуация и ее обработка выходит за рамки самого алгоритма, потому что управлением исполнитель заниматься не должен (опять же, по определению), а должен тот, кто «заказал» выполнение этого действия.
Да, «рабочие» функции должны в этом случае бросать исключения. А концептуально они действительно не отличаются от работы с возвращаемыми значениями, это просто механизм более высокого уровня для выполнения той же задачи — и об этом автор пишет в своей статье.
> Нет концептуальной разницы между «нештатной» и «штатной» ситуацией
Есть для любого организованного технологического процесса. АПП Вам в руки.
Управление на основе исключений — дурной тон в любом языке программирования. Если оно необходимо — значит была допущена ошибка при проектировании системы.
Да, «рабочие» функции должны в этом случае бросать исключения. А концептуально они действительно не отличаются от работы с возвращаемыми значениями, это просто механизм более высокого уровня для выполнения той же задачи — и об этом автор пишет в своей статье.
> Нет концептуальной разницы между «нештатной» и «штатной» ситуацией
Есть для любого организованного технологического процесса. АПП Вам в руки.
Управление на основе исключений — дурной тон в любом языке программирования. Если оно необходимо — значит была допущена ошибка при проектировании системы.
Вы вообще-то что-то крупнее «hello, world» программировали? Где есть больше одного модуля и надо разграничить области видимости и функциональные компоненты? Если я пишу библиотеку с заданным функционалом — я не могу в ее «рабочих» функциях держать «все время держать в голове архитектуру всей программы» — она мне просто неизвестна. Зато я могу сказать, что есть ряд возможных ситуаций, когда нормальное выполнение алгоритма невозможно. Это как раз и есть «нет записи в таблице», «невозможно подключиться к узлу», «недостаточно свободной памяти». Таких ситуаций всегда ограниченное количество и пользователь моей библиотеки узнает об их возникновении как раз отлавливая бросаемые исключения — сигналы о возникновении проблемы.
> Ну и в качестве дополнения…
Если Вы можете (архитектура допускает) — то ради бога, делайте все проверки и соответствующие действия в рамках одного блока программы. Исключения тут и не нужны. А если не можете? Функции f1 не хватило памяти для работы, всю память съела функция f2. Так что, будем организовывать очистку памяти f2 из f1? Наверное нет, мы сообщим «f1 не хватает памяти» тому, кто ее вызвал, а тот уже пусть принимает решение, освобождать занятую память или нет. Это не разработчика f1 задача. Его задача — сказать «я предвижу такую, такую и такую ситуацию, когда функция не сможет работать нормально».
Управление исключениями — это когда без возникновения нештатной ситуации кидается исключение вместо возврата соответствующего результата функции. Это — дурной тон. Welcome to Real World.
> Ну и в качестве дополнения…
Если Вы можете (архитектура допускает) — то ради бога, делайте все проверки и соответствующие действия в рамках одного блока программы. Исключения тут и не нужны. А если не можете? Функции f1 не хватило памяти для работы, всю память съела функция f2. Так что, будем организовывать очистку памяти f2 из f1? Наверное нет, мы сообщим «f1 не хватает памяти» тому, кто ее вызвал, а тот уже пусть принимает решение, освобождать занятую память или нет. Это не разработчика f1 задача. Его задача — сказать «я предвижу такую, такую и такую ситуацию, когда функция не сможет работать нормально».
Управление исключениями — это когда без возникновения нештатной ситуации кидается исключение вместо возврата соответствующего результата функции. Это — дурной тон. Welcome to Real World.
Если кидается исключение, значит функция не может подготовить результат.
Это же очевидно, что вы хотели этим сказать?
Что это не дурной тон по мнению alexkolzov
Верно. Если функция не может выполнить свою задачу — кидается исключение, которое может быть обработано там, где это приемлемо с точки зрения архитектуры системы. Это не дурной тон, а прекрасная практика. Дурной тон — перекидывать управление с места на место путем возбуждения исключений там, где реальной исключительной ситуации нет.
Можете привести пример, где дурно использовать исключение? Пример штатной ситуации.
Приведу слегка утрированный.
Выглядит довольно глупо, но что-то наподобие этого мне приходилось видеть неоднократно, когда пытались сделать разделение обработчиков различных результатов функции. Здесь нет никакой особенной, ошибочной ситуации а исключения используются как способ передачи управления. Вот это — дурной тон.
def method(self, i_value) :
if isinteger(value) :
raise IntegerValue(i_value)
else :
raise NotIntegerValue(i_value)
Выглядит довольно глупо, но что-то наподобие этого мне приходилось видеть неоднократно, когда пытались сделать разделение обработчиков различных результатов функции. Здесь нет никакой особенной, ошибочной ситуации а исключения используются как способ передачи управления. Вот это — дурной тон.
Действительно, есть функции, которые знают о «нештатной» ситуации, сами обрабатывают её и выдают ожидаемый результат. Кидать исключение функция не должна. Например, функция фильтра значения, результат которой – отфильтрованное значение. Но на уровне выше бывает важно учесть, как функция отработала, например, учесть, что начальное значение было неверным. Здесь покажется, что удобней использовать коды возвраты, но их не будешь возвращать вместо значения. Тогда либо last_error() или через аргумент, переданный по ссылке (указатель). Но код ошибки мало информативен. На уровне выше нужно тогда знать все возможные коды ошибок. И здесь, я думаю, удобней возвратить вместо кода объект исключения (не кидая его), содержащий в себе всю информацию о «нештатной» ситуации. И тогда очень просто на уровне выше, либо строим логику, учитывая код/класс исключения, либо уже выкидываем это исключение.
Что скажете?
Что скажете?
Извиняюсь, поправлю себя. На уровне выше кроме кода часто нужно знать дополнительную информацию об ошибке — сообщение, причину ошибки и др.
В таких ситуациях, конечно, можно соорудить объект-обертку возвращаемого значения, из которого можно получить информацию о протекании процесса его вычисления, в том числе возникшие проблемы. Я не считаю этот подход удачным, поскольку в функции происходит что-то вроде «сделаю так, как смогу, а там, выше, пусть разбираются, на сколько это правильно». То есть возможно проведение ненужных вычислений. Тут надо либо полностью доверять функции вычисление значения, либо сообщать об исключительной ситуации в момент ее возникновения и доверять принятие решения вызывающему эту функцию. Но такой подход имеет право на жизнь. И все-таки это не «бросание» исключений, не управление исключениями, а всего-лишь специфический тип возвращаемого значения.
Хм… А где — нет?
В том же python'е, к примеру, StopIteration используется для завершения цикла, но даже там прямо сказано «This is derived from Exception rather than StandardError, since this is not considered an error in its normal application». И уж точно он не используется для «передачи на несколько уровней вверх».
В том же python'е, к примеру, StopIteration используется для завершения цикла, но даже там прямо сказано «This is derived from Exception rather than StandardError, since this is not considered an error in its normal application». И уж точно он не используется для «передачи на несколько уровней вверх».
Где-то год назад Страуструп проводил лекцию в Москве для разработчиков Parallels. Сам я на ней не был, поскольку к тому времени там уже не работал, но рассказывали бывшие коллеги. Ему задали вопрос, что больше всего ему не нравится в С++ (очевидцы, поправьте меня, если я перефразировал не корректно). Он дал лаконичный ответ: «Exceptions».
Что это означает и почему он так считает, я не знаю. За что купил… :-)
Что это означает и почему он так считает, я не знаю. За что купил… :-)
Он такого не мог сказать, по крайней мере весь материал строится на том, что нужно и полезно юзать исключения, а не коды ошибок в виде возвращаемого значений. Единственное что он говорит по поводу исключений в С++, что могло бы хоть как-то навести на мысль что он против С++ исключений, так это «некоторые программисты находят удобным разделение на logic_error, runtime_error, я нет»! Если бы он был против исключений, уверяю, его харизмы хватило бы на изменения в стандарте!
Не хватило бы. По причинам обратной совместимости
Ну выкидывание происходит не за один присест, а поэтапно! С надписями depricated и другими уведомлениями.
Это же не Java, где Oracle могут диктовать свои условия. В C++ такая фишка не прокатит. Может и планируется когда-нибудь в отдаленном будущем в десятом стандарте исключить исключения (простите за каламбур), но скорее всего их оставят как элемент языка даже если Бьерн будет против.
Я думаю, что он всё-таки имел в виду не то, что ем не нравятся исключения как концепция, а то, как они реализованы в C++. В плюсах действительно механизм exceptions не очень логичный — в качестве исключений можно бросать объекты по значению, по ссылке, по указателю, типы объектов исключений тоже могут быть любыми. Всё это вместе означает, что для того, чтобы всё обработалось везде как нужно, чтобы не возникло потери информации в исключении (какие-нибудь «срезки» объектов), чтобы нигде не произошло утечки памяти от программиста требуется либо очень внимательное программирование, либо самоограничение в использовании доступных механизмов exception. Например, часто настоятельно советуют перехватывать exceptions исключительно по константой ссылке, считается, что это наиболее оптимальный вариант перехвата, но сам язык этого не диктует.
Нет, это он не имел в виду.
Этот вопрос ему в том году задавали, когда он выступал в Бауманке (просто помещение, так это была конференция за 5к) — дескать, почему не заставить всех наследовать исключения от ::std::exception. Ответ был универсальным — «зачем? хочется — введите coding standard, а так прелесть плюсов в том, что все можно и каждый сам задает свои ограничения».
К сожалению аналогичный ответ был и на вопрос «почему всего 5 типов итераторов и они не разделяются на только чтение, только запись», и на вопрос «почему с++ не заботится о переполнении стека, столько ж механизмов напридумывали — стандартизируйте уже наконец!».
Этот вопрос ему в том году задавали, когда он выступал в Бауманке (просто помещение, так это была конференция за 5к) — дескать, почему не заставить всех наследовать исключения от ::std::exception. Ответ был универсальным — «зачем? хочется — введите coding standard, а так прелесть плюсов в том, что все можно и каждый сам задает свои ограничения».
К сожалению аналогичный ответ был и на вопрос «почему всего 5 типов итераторов и они не разделяются на только чтение, только запись», и на вопрос «почему с++ не заботится о переполнении стека, столько ж механизмов напридумывали — стандартизируйте уже наконец!».
Вам бы познакомиться с обработкой ошибок в эрланге =)
Не знаю почему минусуют. Но как раз в эрланге основной принцип: «не можешь сделать — умри» плюс гибкая система супервизоров и апгрейда на лету и есть более надёжная альтернатива «распространению ошибок» по-всему приложению. Вообще эрланг это скорее язык управления, а не вычислений. К сожалению в С/С++ такое применимо только в специфических приложениях.
Единственный важный момент про C++ и исключения, особенно в контексте библиотек:
Не везде исключения можно использовать. Например в исключения не должны пересекать границы Dll-ки почти никогда. Поскольку их будет возможно обработать только из плюсов.
Мне кажется разумным правило никогда не использовать исключения в случае если нужна бинарная совместимость с дргими языками/компиляторами и отдавать им предпочтение во всех остальных случаях.
Не везде исключения можно использовать. Например в исключения не должны пересекать границы Dll-ки почти никогда. Поскольку их будет возможно обработать только из плюсов.
Мне кажется разумным правило никогда не использовать исключения в случае если нужна бинарная совместимость с дргими языками/компиляторами и отдавать им предпочтение во всех остальных случаях.
В мире не только dll бывают, а это ещё веселее. Поэтому для кроссплатформенных прог есть шанс рано или поздно наткнуться на невозможность юзать исключения.
Вообще говоря, я согласен. Но это может быть связано только с поломанным компилятором. Я прямо сейчас колбашу кросплатформенный проект на более чем полтора десятка разных платформ и на более чем 5 архитектур процессора. И мы приняли решение перейти к исользованию исключений повсеместно.
Поскольку у нас сложилось впечатление, что чинить поддержку исключений часто бывает намного проще, чем поддерживать коды возвратов для большОго количества подсистем и архитектур.
Но это такое. Каждый выбирает инструмент на свой вкус. Главное что бы выбор был обоснован и следовали этому выбору все.
Поскольку у нас сложилось впечатление, что чинить поддержку исключений часто бывает намного проще, чем поддерживать коды возвратов для большОго количества подсистем и архитектур.
Но это такое. Каждый выбирает инструмент на свой вкус. Главное что бы выбор был обоснован и следовали этому выбору все.
Очень интересное обсуждение по теме (eng): discuss.joelonsoftware.com/default.asp?joel.3.125056.21
Обсуждается, собственно, вот эта статья:
www.joelonsoftware.com/items/2003/10/13.html
И эта:
blogs.msdn.com/b/oldnewthing/archive/2005/01/14/352949.aspx
www.joelonsoftware.com/items/2003/10/13.html
И эта:
blogs.msdn.com/b/oldnewthing/archive/2005/01/14/352949.aspx
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Коды возврата & исключения