Comments 28
Забыли еще пункт «мой environment разработки не поддерживает исключения»
UFO just landed and posted this here
Re: Мой код идеален, в нем не бывает ошибок
Ваши функции или возвращают код ошибки или кидают исключения, третьего не дано. Нет прямой связи между использованием исключений и наличии ошибок в программе. Если, конечно, не считать ошибкой отсутствие «обработки исключений».
Ваши функции или возвращают код ошибки или кидают исключения, третьего не дано. Нет прямой связи между использованием исключений и наличии ошибок в программе. Если, конечно, не считать ошибкой отсутствие «обработки исключений».
1) Как Вы обойдете вычисление квадратного корня от отрицательного числа на С++?
2) Как Вы обойдете вычисление квадратного корня от отрицательного числа на Java?
2) Как Вы обойдете вычисление квадратного корня от отрицательного числа на Java?
А почему я должен это обходить? Если функция не может сделать то, что должна, она обязана сообщить об этом вызывающей функции: выкинуть соответствующее исключение или вернуть код ошибки. ИМХО.
Ну например по принципу lets it crash
И плюс, то что у нас С++ никак не гарантирует того что у нас есть exception.
И плюс, то что у нас С++ никак не гарантирует того что у нас есть exception.
UFO just landed and posted this here
Ещё забыли «trap_exit наше всё»
Об исключениях знаю давно, но как-то привык возвращать или true/false или int-овский return code. На самом деле, не помешала бы статья, в которой рассказывается, почему исключения лучше и полезнее.
Если взять php, то с помощью исключений можно получить дополнительные данные об ошибке (не изобретая велосипедов), например название функции, класса, номер строки, имя файла для дальнейшего анализа, ну и весь трейс выполнения скрипта.
Как раз готова уже небольшая статья, опрос был опубликован для нее.
Нету пункта, «использую везде, где это требуется и подходит»…
Активно использую исключения и с трудом понимаю как я раньше жил без них. В ряде ситуаций возникновение и обработка ожидаемых исключений является у меня частью реализации алгоритма.
Ещё очень люблю (в то время как существует мнение что это форменный абсурд) NotImplementedException (System.NotImplementedException в .Net и org.apache.commons.lang.NotImplementedException в Scala/Java) — позволяет буквально строить программу как дом по кирпичикам и уже жить в уже построенной комнате, постепенно достраивая остальное: можно скомпилить (таким образом уже частично проверив) и частично отдебажить/протестировать программу когда некоторые (и даже многие) её функции уже определены, но ещё не написаны. Первым делом пишу «каркас» класса со всемим функциями, прописываю в них всех вместо реализации throw new NotImplementedException() и постепенно начинаю реализовывать одну за другой (при этом одна может ссылаться на другую, ещё не реализованную, и программа при этом должна скомпилится).
Ещё очень люблю (в то время как существует мнение что это форменный абсурд) NotImplementedException (System.NotImplementedException в .Net и org.apache.commons.lang.NotImplementedException в Scala/Java) — позволяет буквально строить программу как дом по кирпичикам и уже жить в уже построенной комнате, постепенно достраивая остальное: можно скомпилить (таким образом уже частично проверив) и частично отдебажить/протестировать программу когда некоторые (и даже многие) её функции уже определены, но ещё не написаны. Первым делом пишу «каркас» класса со всемим функциями, прописываю в них всех вместо реализации throw new NotImplementedException() и постепенно начинаю реализовывать одну за другой (при этом одна может ссылаться на другую, ещё не реализованную, и программа при этом должна скомпилится).
Попробуйте попрограммировать на C++…
Не совсем очевидно, что вы хотите сказать этим комментарием. Если человек умеет программировать на С++, то вы ему советуете делать то, что он и так делает. Если он на С++ никогда не программировал — он вас не поймет.
Попробуйте попрограммировать на Эрланге. Просто так.
Что Вы имеете в виду под «обработка ожидаемых исключений является у меня частью реализации алгоритма»? Если я Вас правильно понял, то в моем понимании программировать «через исключения» это плохо, а главное медленно.
Пишу на ассемблере, что такое исключения знаю :)
Как ответить?
Как ответить?
Ахах, за такой опрос надо по пальцам бить! Может кто нибудь знает как можно с помощью «идеального кода», обойтись без исключений на уровне DAO? ;)
Когда учился программировать (на С++) и дошел до главы исключения — не понял как их использовать и избегал их. Со временем дошло, что и как. Исключения вообщем хорошая штука, без которой я сейчас трудно представляю высокоуровневое программирование.
В своём опросе как и в статье Вы совершенно не учитываете (не понимаете?...) один важный момент: исключения и ошибки это разные вещи. Они служат разным целям, должны управляться разными механизмами и имеют совершенно разные требования к производительности.
Пункты «Коды ошибок — наше все» и «Мой код идеален, в нем не бывает ошибок» — не имеют смысла в опросе про исключения.
Пункты «Коды ошибок — наше все» и «Мой код идеален, в нем не бывает ошибок» — не имеют смысла в опросе про исключения.
ИМХО, всё зависит от того, на сколько вероятно возникновение ошибки:
— если у вас есть функция, которая не сможет отработать только в исключительных (простите за каламбур) условиях (5-10% случаев) — то бросать исключение. К примеру, функция чтения файла, при условии предварительной проверки пути к нему и прав доступа.
— если у вас функция, которая не сможет отработать в достаточно большом количестве случаев, тогда скорее возврат чего-либо из неё (к примеру, Null вместо указателя), и проверка результата.
К примеру,
if ((a = GetRoot2(b)) != null){}
else {}
Основная моя идёт вот в чём: всё зависит от статистической вероятности «исключения», дороговизны его обработки и упрощения отладки. Ошибки, у которых большая степень вероятности, статистически дешевле обрабатывать за счёт возврата. Исключения же стоит использовать:
-при отладке(ваш К.О.),
-для маловероятных ошибок, которые все-же можно предусмотреть и после них восстановится,
-для отлова ошибок, которые не удалось предусмотреть заранее и после них программа не умеет восстанавливаться — скорее всего, обработчик на очень высоком уровне будет пытаться сохранить возможные данные пользователя и отправить отчет разработчику.
— если у вас есть функция, которая не сможет отработать только в исключительных (простите за каламбур) условиях (5-10% случаев) — то бросать исключение. К примеру, функция чтения файла, при условии предварительной проверки пути к нему и прав доступа.
— если у вас функция, которая не сможет отработать в достаточно большом количестве случаев, тогда скорее возврат чего-либо из неё (к примеру, Null вместо указателя), и проверка результата.
К примеру,
if ((a = GetRoot2(b)) != null){}
else {}
Основная моя идёт вот в чём: всё зависит от статистической вероятности «исключения», дороговизны его обработки и упрощения отладки. Ошибки, у которых большая степень вероятности, статистически дешевле обрабатывать за счёт возврата. Исключения же стоит использовать:
-при отладке(ваш К.О.),
-для маловероятных ошибок, которые все-же можно предусмотреть и после них восстановится,
-для отлова ошибок, которые не удалось предусмотреть заранее и после них программа не умеет восстанавливаться — скорее всего, обработчик на очень высоком уровне будет пытаться сохранить возможные данные пользователя и отправить отчет разработчику.
Sign up to leave a comment.
Как вы относитесь к использованию исключений в коде?