А стоит ли распинаться в коде?

[Alex Cones]

Пишу код. И ВНЕЗАПНО приходит мысль - а стоит ли вообще расписывать все проверки\ошибки etc.? В данный момент код вида:

Else
    Begin
     Compress := 'ERROR C2.2: TOO SMALL FILE - INFO HEADER NOT FOUND';
     DF := FALSE;
    End;
   If (DF) And (BFH.bfType <> $4D42) Then
    Begin
     Compress := 'ERROR C3: NOT BMP FILE';
     DF := FALSE;
    End;
   If (DF) And (BFH.bfSize <> FileSize(F)) Then
    Begin
     Compress := 'ERROR C4.1: BROKEN STRUCTURE - WRONG FILE SIZE';
     DF := FALSE;
    End;
   If (DF) And (BFH.bfReserved = 0) Then
    Begin
     Compress := 'ERROR C4.2: BROKEN STRUCTURE - RESERVED BLOCK HAS WRONG VALUE';
     DF := FALSE;
    End;

ну в общем таких блоков over9000. Так стоит ли ставить все эти проверки? Или оставить все "наголо"? Вылетит так вылетит, подсунут файл неправильный - fаil программы - ну дык на зеркало неча пенять, коли рожа крива.
P.S. Это dll, есть шанс, что попадет в общий доступ без сорса.

P.P.S. Тема не относится к разделу Delphi, поскольку обсуждается не код, а сам тип программирования.

[Levsha100]

Compress := 'ERROR C4.2: BROKEN STRUCTURE - RESERVED BLOCK HAS WRONG VALUE';

А не проще ли оформить процедуру и передавать ей только номер?

А если подумать над самой сутью вопроса?

Это сложно, ибо не известно:
1)На сколько часто будут возникать ошибки
2)Какие их последствия
3)Распространненость программы и ее конечные пользователи.
Все эти параметры нужно взвесить.

Но, имхо, все же стоит.

[Alex Cones]

А не проще ли оформить процедуру и передавать ей только номер?

А какая разница, что вернет функция? Integer или ShortString? Так хоть понятней будет.

P.S. А если подумать над самой сутью вопроса?

1)На сколько часто будут возникать ошибки

Подсунут неправильный файл или битый - будут. Иначе - не должны.

2)Какие их последствия

Ну какие обычно последствия при том, что функция ВДРУГ не работает?

3)Распространненость программы и ее конечные пользователи.

DLL с функциями архивации bmp файлов. Насчет конечного пользоателя - цепь: я - программисты - пользователи.
А вот насчет распространенности не знаю. Допишу, а там посмотрим...

[raxp]

как вариант выдавать код ошибки... а по ним отдельный мануальчик, потом.

[Alex Cones]

как вариант выдавать код ошибки... а по ним отдельный мануальчик, потом.

Т.е. я так понимаю это голос "за"? А вот насчет кода ошибки -я подумаю над этим. Хотя при передачи 255 байт вроде не должно быть проблем. Хотя... Ладно, буду передавать BYTE, а рядом положу мануал.

[Arigato]

Странный код. Проще сделать отдельно функцию, генерирующую код ошибки, а далее, список стринговых констант - описание ошибок по коду.
И не придётся 100 раз писать одно и тоже:

    Begin
     Compress := '...';
     DF := FALSE;
    End;

[alexinspir]

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

[Пепел Феникса]

Алекс, считаю что нужно, ибо всетаки нужно ошибки обработать...а не надеятся на авось...
кстати Byte бесмысленно, лучше уж Integer(LongInt для стабильности) ибо один фиг регистр eax идет...а при byte просто его часть(al скорее всего)
так что проверять и проверять
разве что можно оптимизировать код.

[Ivan_32]

Тема видимо о защите от дурака? Смотря с чем работаете. Лучше конечно сделать в DLL безопасные и небезопасные функции, вторые быстрее будут работать на пару сотен тактов(конечно это зависит от конкретной платформы итд и от количество обработчиков ошибок).
Таким образом предоставите пользователям выбор каким путем пойти.
А что касается программы то опять же смотря что является объектом и кто будет управлять этим объектом - программист(в случае с вашей ДЛЛ) или пользователь. Допустим если вы пишите сервисный драйвер(не устройства) - стоит позаботится о обоих видах функций. В вашем случае можно обойтись небезопасными функциями так как оперировать объектом будет программист. В случае если что то пишется для пользователей - лучше использовать безопасные функции, т.к. это все же пользователи. Я так же считаю что нельзя лишать программистов права на использование небезопасных функций при условии что объектом является нечто, сильно-зависимое от производительности вашего кода.

[pu4koff]

Мне бы не понравился, например, антивирус, который вылетает с ошибкой типа "Cannot create socket" при отключенном интернете, пытаясь обновить базы с сайта.
Необработанные исключения в общем случае легко приводят к краху всей программы. Причем программа не обязательно "умрёт", а просто будет непонятно как работать. Если Вас это не пугает, то не заморачивайтесь на счет этого.
А если уж решите так оставить, то не забывайте в своём коде ловить чужие исключения, чтобы программа не рухнула в непонятном месте, а функция как и полагается вернула код/текст ошибки. Функции с таким способом оповещения об ошибках должны гарантировать, что из них исключения не вывалятся, а иначе во всём этом нет смысла.
Так же если будет таки переход на систему исключений, то так же нужно и внутри своих функций ловить исключения. Каждая функция должна возвращать фиксированный набор исключений, а не так, что сейчас мы внутри этой функции используем библиотеку №1, которая может выбросить такие то исключения, а завтра перешли на библиотеку №2 и бросаемся совсем другими исключениями. Опять же, не пойманное исключение - потенциальная опасность нарушения работоспособности программы и утечек памяти.