Обработчик ошибок , Писать или не писать?

1. Ошибка может произойти на любой исполняемой строке. Спорить на эту тему не буду, т.к. я проиграю спор. Я должен либо доказать мое утверждение теоретически, либо на каждую линию, приведенную оппонентом, привести пример ошибки.

2. Я лично пишу код с багами. Если кто умеет писать идеальный код, который никогда не сбивается, то честь ему и хвала. Я так не умею.

3. Я не хочу тратить много времени на поиск места и причину ошибки, когда она все-таки случается.

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

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

У кого другое мнение?

Предпочитаю баги ловить(если они есть) в момент их проявления.
Ну зачем делать обработчик на стоку a=b/c ? И так видно, что проверку на "с" необходимо ставить.
С массивами та же проблема. Четко знаешь пределы - лови индекс в этих значениях.
Ну и т.п. мне проще исключить глючные варианты, чем багить их, а потом всеравно исключать.

Цитата MIF @ 03.10.06, 08:21

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

Для этого в Delphi есть механизм исключений, который, в купе с JCL Stack Tracing, дает то же самое без лишних телодвижений. Только отладочную информацию добавить нужно.

Но вообще-то к написанию кода без ошибок стоит стремиться.

Добавлено 03.10.06, 08:38

Цитата Black Star @ 03.10.06, 08:34

Ну и т.п. мне проще исключить глючные варианты, чем багить их, а потом всеравно исключать.

Согласен, не люблю лишние проверки, они тормозят и отвлекают от основной идеи. Лучше контроллировать входные параметры (на уровне GUI, например). На крайний случай - ставлю Assert.

Цитата Black Star @ 03.10.06, 08:34

И так видно

Ограничения не всегда очевидны. Здесь сказано, что нужно делать проверку на х = - 1, на самом деле - на х = 0.

Цитата MIF @ 03.10.06, 08:43

Ограничения не всегда очевидны. Здесь сказано, что нужно делать проверку на х = - 1, на самом деле - на х = 0.

эээ... если я правильно понял, ссылка ведёт на мой пост в разделе VB? тогда вот цитата из него, чтоб не ходить лишний раз.

Цитата Змей(Чёрный), 03.10.2006, 2:05:41, 1287990

function f(x as long) as long
f=1/x+1
end function

как ни парадоксально, проверять надо не на 0, а на -1. (если передать функции 0, получим f=1/0+1 ( f=1/1, f=1))

а вот если передать -1, получаем -1+1=0 и вылетаем с делением на 0, "Run-time error 11, Division by zero"

Вообще, я не против обработчиков ошибок, но далеко не все ошибки НУЖНО обрабатывать, чаще оказывается намного более простым просто не допустить их.

Змей(Чёрный), я делаю такие же ошибки, поэтому пишу обработчик ошибок. Скобок то в коде нет.

ой, блин! дошло! я скобки забыл, формула должна быть f=1/(x+1)тем не менее, обрабатывать подобную ошибку не надо!!! она возникла из-за моей невнимательности, и только рантайм-еррор мог бы указать на неё.

Цитата Змей(Чёрный) @ 03.10.06, 11:31

ой, блин! дошло! я скобки забыл

А я-то сижу, и думаю - и где такую траву взял А это очепятка ж

Цитата Астарот, 03.10.2006, 14:44:22, 1288779

А я-то сижу, и думаю - и где такую траву взял

не, это не трава, это антибиотики...

просто когда писАл формулу - представлял её в виде дроби, а в дробях скобки не ставят...

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

Цитата MIF @ 03.10.06, 08:21

Ошибка может произойти на любой исполняемой строке. Спорить на эту тему не буду, т.к. я проиграю спор. Я должен либо доказать мое утверждение теоретически, либо на каждую линию, приведенную оппонентом, привести пример ошибки.

Всё проще. Компиляторы тоже не безгрешны, никто не может гарантировать, что он сгенерирует адекватный код. Также никто не застрахован от аппаратных сбоев. Так что ошибок можно ожидать откуда угодно.

Цитата MIF @ 03.10.06, 08:21

У кого другое мнение?

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

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

Дальше есть варианты. Восстановление от ошибок в структурных программах затруднительно. Поэтому при внутренних ошибках я обычно делаю abort. Assert'ов кстати много не бывает. Особенно хорош откомментированный ассерт с указанием возможной причины, типа assert(ptr->index == 0 && "oops... uninitialized structure?"). Обязательно ставлю assert перед каждым первым разыменованием указателя в функции. Ну а пользовательские ошибки (и ошибки среды) должны обрабатываться штатно. Я обычно проверю все возвращаемые значения вплоть до fclose().

В ООП всё проще. Можно бросаться исключениями, грамотное использование которых позволяет восстанавливаться даже после серьезных внутренних сбоев.

Ну а функциональное программирование -- сказка. Там обрабатывать ошибки почти не надо.

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

Цитата

ДА обработчикам ошибок, там где без них не обойтись.

Сообщение отредактировано: Seriy-Coder - 04.10.06, 13:47

Цитата

Естественно чем больше процедура/функция тем более вероятен в ней баг

Слишком большая функция уже сама по себе является ошибкой, ассертом она не выловится .

Цитата

Assert'ов кстати много не бывает

Мамой клянусь - он прав.

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

Но! Не надо забывать, что во всех случаях существуют:
drWatson (для Windows), который ловит программынй сбой на клиенте и может записать информацию начиная от простейшего stack-трейса, до mini- и full-дампа.
core-файлы (для Unix), по которым состояние программы востанавливается на момент сбоя.

Эти две возможности делают фактически ненужными сложные обработчики ошибок. Ибо зачем изобретать велосипеды, отягощать release-версию программы отладочной информацией и т. п.? Сбой произошел, клиент присылает тебе дампы с логами, и ты у себя в спокойной обстановке все это дело анализируешь. Особенно хорошо в этом помогают mini-дампы, ибо наличия отладочной информации они не требуют, а ты, получив такой дамп и имея на руках отладочную инфу, можешь достаточно легко востановить - где и при какаих обстоятельствах "рвануло".

Вот тебе, так сказать, альтернативное мнение.

Flex_Ferrum, я с тобой конечно, соглашусь, но частично. Для целей отладки именно лучше побольше ассертов понаставить . Уже на этапе разработки разобрать все противоречивые ситуации.
Я тут у себя одну багу нашёл.. жила бага 4 месяца и никто о ней не знал. Я о ней тоже не знал, пока ассерт не установил. Так бы и рвануло где нибудь с удесятерённой силой ПОТОМ. Ошибку на этапе разработки поймать дешевле, а тут ассерт - наипервейший помошник. Можно конечно потом и .map info рыть, и т.д., но это дольше и значительно менее интересно.