Re: Трубопровод в Linux
В сообщении от 1137010705 секунд после начала Эпохи Владимир Ковалев написал(а):
> > > просто прерывать исполнение. Обычно здесь не надо печатать никаких
> > > сообщений. Эти проверки показывают наличие ошибок. Если кто-то захочет
> > ? Считаете что пользователю от этого станет легче?
> Ну хотя бы узнает, что произошла ошибка.
Т.е. мы пишем для идиотов. :) Нормальные люди и так поймут что
произошла ошибка, причем, так сказать, незапланированная.
> > Возможно вы не правильно поняли цитату. "Невозможные условия" я
> > понимая как условия, которые при нормальной работе программы (как это
> > планируется) никогда не должны выполнятся. Например:
> > unsigned a,b,c;
> > ...
> > c = a + b;
> > if (c < a) {
> > exit(1);
> > }
> Если Я пишу МОЮ программу и допускаю в ней "ляп" наподобие приведенного Вами,
где ляп? Попробуйте скомпилировать и выполнить:
#include <stdio.h>
int main(int argc, char **argv) {
unsigned a = 1, b = (unsigned)(-1), c;
c = a + b;
if (c < a)
printf("Error!\n");
return 0;
}
А теперь представьте что вместо `b = (unsigned)(-1)' стоит `b =
some_lib_func()'.
Конечно же это упрощенная модель, но алгоритмы могут быть настолько
сложными что подобные ситуации уже не будут очевидными.
> то
> это, ИМХО, не программирование. И проверки на такие ситуации допустимы только
> на
> этапе тестирования программы. Ибо, если возникновение подобной ситуации
> предусмотренно алгоритмом программы, то должна быть предусмотренна и адекватная
> реакция на ситуацию, иначе необходимо что-то делать с алгоритмом
Все предусмотреть невозможно, особенно когда программа использует чужие
библиотеки/программы. Проблемы несовместимости различных версий нужно
ожидать в любой момент. И когда автор библиотеки X что-то напортачит,
пользователи будут обвинять вас. Так что проверки на казалось бы
невозможные условия, но так или иначе зависящие от поведения библиотек,
при решении ответственных задач, все же желательно делать. Так же
нельзя быть чересчур самоуверенным, и все же понимать что и ваших
алгоритмах могут быть ошибки.
> > Напротив, данные принятые от пользователя нужно проверять, и при
> > недопустимых параметрах, выдавать соответствующее сообщение.
> А вот здесь согласен, пользователь ведь может и ошибиться. И об ошибке ему
> необходимо сообщить незамедлительно, дабы ошибка не привела к каким либо
> непоправимым последствиям Но что делать, если сообщить ему об ошибке мы можем
> только после прекращения работы конвеера, когда результат уже будет получен.
А почему не во время?
> Вариантов, как всегда, три:
> 1) Выдать в stderr сообщение об ошибке, а в stdin не выдавать ни чего.
Обычно так и происходит.
> 2) Проигнорировать неправильный параметр, выдать в stderr сообщение, а в stdin
> продолжить вывод с теми параметрами, которые признаны правильными.
Зависит от конкретной задачи. Но если имеется в виду неправильная
опция, то я считаю, что в такой ситуации нужно сразу выругаться в
stderr и прекратить выполнение с кодом завершения отличным от нуля.
> > Меньше лишнего кода - меньше глюков.
> Согласен полностью, но где граница, за которой увеличение кода гарантированно
> приводит к появлению глюков и наоборот, уменьшение кода гарантированно избавляет
> от глюков.
"гарантированно" - это не наше слово, наши слова - "ну возможно, если
повезет". :) Да и вообще это слово тут неприменимо, гарантии в
магазине. В данном контексте можно только говорит о вероятности.
