Здравствуйте, AlexNek, Вы писали:

AN>Здравствуйте, samius, Вы писали:

AN>>>Так что надо вывалить исключение и сказать пшел вон?
S>>Сначала надо уловить разницу между тем, что является корректным набором данных для метода и нет. В случае некорректного формата данных нужно кидать исключение сразу, так быстрее найдете то место, где они становятся некорректными. Вам Sinclair дал ссылку на FailFast.
AN>Я специально привел пример, когда этого не следует делать.
Этот пример не имеет отношения к случаю проверки аргументов WriteTransformation

AN>>>По мне, так лучше показать пустую страницу и написать внутри что ее невозможно обработать.
S>>Исключение разве мешает это сделать?
AN>Да иногда может.
Иногда может что?

AN>>>Смысл в том что блок распознавания страниц должен всегда выдавать результат, а не передавать исключение наверх, те исключения просто обрабатываются "локально"
S>>Кто этот смысл выдумал?
AN>Наши принципы работы с пользователем
Вашь пользователь работает с WriteTransformation напрямую?

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

Здравствуйте, samius, Вы писали:

S>Здравствуйте, AlexNek, Вы писали:

AN>>Здравствуйте, samius, Вы писали:

AN>>>>Так что надо вывалить исключение и сказать пшел вон?
S>>>Сначала надо уловить разницу между тем, что является корректным набором данных для метода и нет. В случае некорректного формата данных нужно кидать исключение сразу, так быстрее найдете то место, где они становятся некорректными. Вам Sinclair дал ссылку на FailFast.
AN>>Я специально привел пример, когда этого не следует делать.
S>Этот пример не имеет отношения к случаю проверки аргументов WriteTransformation
Это вполне может быть Вашим мнением. У меня оно несколько другое.

AN>>>>По мне, так лучше показать пустую страницу и написать внутри что ее невозможно обработать.
S>>>Исключение разве мешает это сделать?
AN>>Да иногда может.
S>Иногда может что?
Выдача исключения в большинстве случаев подразумевает переход на другой путь, в частности
показ диалога сообщения об ошибке и аврийное прерывания текущей операции.
AN>>>>Смысл в том что блок распознавания страниц должен всегда выдавать результат, а не передавать исключение наверх, те исключения просто обрабатываются "локально"
S>>>Кто этот смысл выдумал?
AN>>Наши принципы работы с пользователем
S>Вашь пользователь работает с WriteTransformation напрямую?
Конечно нет, но эта функция отностися к блоку не имеющему права выдавать исключения.

S>>>Вообще не пойму, причем тут страницы, до сих пор речь шла о WriteTransformation
AN>>Просто как более понятный пример
S>Вы его неверно трактуете.
Тут вопрос кто его неправильно трактует. Возможно мы его понимает по разному.
S>Если все методы приложения будут гнать пургу в ответ на пургу во входных данных, ваше приложение просто будет молча делать пургу вместо того что ожидает пользователь.
никто не ведет речь о всех методах, есть просто различные части с различным "поведением".

Здравствуйте, AlexNek, Вы писали:

AN>Здравствуйте, samius, Вы писали:

AN>>>Я специально привел пример, когда этого не следует делать.
S>>Этот пример не имеет отношения к случаю проверки аргументов WriteTransformation
AN>Это вполне может быть Вашим мнением. У меня оно несколько другое.
очевидно

AN>>>Да иногда может.
S>>Иногда может что?
AN>Выдача исключения в большинстве случаев подразумевает переход на другой путь, в частности
AN>показ диалога сообщения об ошибке и аврийное прерывания текущей операции.
Вообще говоря это не так.
Но в вашем случае WriteTransformation просто продолжит нагнетать пургу. Если вашего пользователя устроит такой подход, то мне нет больше до этого дела.

S>>Вашь пользователь работает с WriteTransformation напрямую?
AN>Конечно нет, но эта функция отностися к блоку не имеющему права выдавать исключения.
Ваш блок даже не выдает код ошибки, а просто гонит. Печально то, что об этом может никто не узнать и считать что блок отрабатывает верно.

AN>>>Просто как более понятный пример
S>>Вы его неверно трактуете.
AN>Тут вопрос кто его неправильно трактует. Возможно мы его понимает по разному.
Вы его понимаете так, будто приложение должно делать то для чего оно написано, даже если данные повреждены.

S>>Если все методы приложения будут гнать пургу в ответ на пургу во входных данных, ваше приложение просто будет молча делать пургу вместо того что ожидает пользователь.
AN>никто не ведет речь о всех методах, есть просто различные части с различным "поведением".
"поведение" вашего блока — нагнетать пургу и делать вид что все ок.

Здравствуйте, samius, Вы писали:

S>Здравствуйте, AlexNek, Вы писали:

AN>>Здравствуйте, samius, Вы писали:

AN>>>>Я специально привел пример, когда этого не следует делать.
S>>>Этот пример не имеет отношения к случаю проверки аргументов WriteTransformation
AN>>Это вполне может быть Вашим мнением. У меня оно несколько другое.
S>очевидно
И при этом я не хочу утверждать что мое правильное или Ваше нет.

AN>>>>Да иногда может.
S>>>Иногда может что?
AN>>Выдача исключения в большинстве случаев подразумевает переход на другой путь, в частности
AN>>показ диалога сообщения об ошибке и аврийное прерывания текущей операции.
S>Вообще говоря это не так.
А как?
S>Но в вашем случае WriteTransformation просто продолжит нагнетать пургу. Если вашего пользователя устроит такой подход, то мне нет больше до этого дела.
Что значи нагнетать пургу? Если данные переданы неправильно, то пользователь в любом случае не получит правильного ответа и он об этом будет знать.
S>>>Вашь пользователь работает с WriteTransformation напрямую?
AN>>Конечно нет, но эта функция отностися к блоку не имеющему права выдавать исключения.
S>Ваш блок даже не выдает код ошибки, а просто гонит. Печально то, что об этом может никто не узнать и считать что блок отрабатывает верно.
А у него такая задача не прерывать цепочку, чтобы не случилось.

AN>>>>Просто как более понятный пример
S>>>Вы его неверно трактуете.
AN>>Тут вопрос кто его неправильно трактует. Возможно мы его понимает по разному.
S>Вы его понимаете так, будто приложение должно делать то для чего оно написано, даже если данные повреждены.
А что бы вы предложили?
S>>>Если все методы приложения будут гнать пургу в ответ на пургу во входных данных, ваше приложение просто будет молча делать пургу вместо того что ожидает пользователь.
AN>>никто не ведет речь о всех методах, есть просто различные части с различным "поведением".
S>"поведение" вашего блока — нагнетать пургу и делать вид что все ок.
В данном случае задача формулируется так: если регулировщика переехала машина перекресток должен остаться регулируемым, пусть даже и строго в одном направлении.
Вполне возможно, что кто то может сказать блин — это ведь негуманно, давайте остановим движение и спасем регулировщика.

Здравствуйте, AlexNek, Вы писали:

AN>Здравствуйте, samius, Вы писали:

AN>И при этом я не хочу утверждать что мое правильное или Ваше нет.
Я тоже ничего не утвреждаю по поводу правильности мнений. Делюсь своим. Не нужно — только намекните.

AN>>>Выдача исключения в большинстве случаев подразумевает переход на другой путь, в частности
AN>>>показ диалога сообщения об ошибке и аврийное прерывания текущей операции.
S>>Вообще говоря это не так.
AN>А как?
Исключения бывают ожидаемыми и обрабатываемыми. Недостаточно данных для работы — нужно сказать пользователю что их недостаточно для работы. Не обязательно при этом делать вид что все работает, или показывать диалог с аварийным завершением.

AN>Что значи нагнетать пургу? Если данные переданы неправильно, то пользователь в любом случае не получит правильного ответа и он об этом будет знать.
Вы предлагаете ему самому догадаться что в неком блоке с запретом на исключения в метод WriteTransformation пришли неправильные данные и в итоге он получил не то что хотел? А вдруг, то что он увидит в результате он примет за верный результат? У вас даже программа не знает о том что что-то пошло не так. Так откуда пользователь об этом будет знать?

S>>Ваш блок даже не выдает код ошибки, а просто гонит. Печально то, что об этом может никто не узнать и считать что блок отрабатывает верно.
AN>А у него такая задача не прерывать цепочку, чтобы не случилось.
Это весьма странно. Зачем нужна цепочка, которая не гарантирует результат?

AN>>>>>Просто как более понятный пример
S>>>>Вы его неверно трактуете.
AN>>>Тут вопрос кто его неправильно трактует. Возможно мы его понимает по разному.
S>>Вы его понимаете так, будто приложение должно делать то для чего оно написано, даже если данные повреждены.
AN>А что бы вы предложили?
fail fast. В этом случае вы хотя бы узнаете, что нечто пошло не так и сможете сказать об этом пользователю, он обратится к вам и вы позже исправите ситуацию.

S>>"поведение" вашего блока — нагнетать пургу и делать вид что все ок.
AN>В данном случае задача формулируется так: если регулировщика переехала машина перекресток должен остаться регулируемым, пусть даже и строго в одном направлении.
Он не будет регулируемым, он будет регулируемым хаотически

AN>Вполне возможно, что кто то может сказать блин — это ведь негуманно, давайте остановим движение и спасем регулировщика.
В вашем случае никто не узнает что что-то произошло и все будут делать вид что так и должно быть.

Здравствуйте, AlexNek, Вы писали:

S>>Ваш блок даже не выдает код ошибки, а просто гонит. Печально то, что об этом может никто не узнать и считать что блок отрабатывает верно.
AN>А у него такая задача не прерывать цепочку, чтобы не случилось.

Запет на выброс исключений это совсем не картбланш на GI/GO (Garbage In — Garbage Out). Корректность входных данных проверять всеравно необходимо, и функция, которая не использует исключения для сигнализации, данных должна возвращать код результата (ошибки).

Здравствуйте, samius, Вы писали:

S>Здравствуйте, AlexNek, Вы писали:

AN>>Здравствуйте, samius, Вы писали:

AN>>И при этом я не хочу утверждать что мое правильное или Ваше нет.
S>Я тоже ничего не утвреждаю по поводу правильности мнений. Делюсь своим. Не нужно — только намекните.
Ну почему, из любой дискуссии можно вынести что то полезное.

AN>>>>Выдача исключения в большинстве случаев подразумевает переход на другой путь, в частности
AN>>>>показ диалога сообщения об ошибке и аврийное прерывания текущей операции.
S>>>Вообще говоря это не так.
AN>>А как?
S>Исключения бывают ожидаемыми и обрабатываемыми. Недостаточно данных для работы — нужно сказать пользователю что их недостаточно для работы. Не обязательно при этом делать вид что все работает, или показывать диалог с аварийным завершением.
То бишь функцию лучше обвернуть в тру/сатч который нифига не делает?

AN>>Что значи нагнетать пургу? Если данные переданы неправильно, то пользователь в любом случае не получит правильного ответа и он об этом будет знать.
S>Вы предлагаете ему самому догадаться что в неком блоке с запретом на исключения в метод WriteTransformation пришли неправильные данные и в итоге он получил не то что хотел? А вдруг, то что он увидит в результате он примет за верный результат? У вас даже программа не знает о том что что-то пошло не так. Так откуда пользователь об этом будет знать?
Любой "пользователь" об этом узнает.
Если расматривать реального пользователя, то он оправляет некую команду на выполнение, а в результате получает сообщение, что команда выполнилась неправильно (так как ожидаемые данные не были получены). Если расмматривать пользователя- приемника информации, то он получает даже больше чем нужно. Он получает всего лишь один байт, что невозможно. Поэтому он знает что была просто неверная передача, а не то что клиент свалил.

S>>>Ваш блок даже не выдает код ошибки, а просто гонит. Печально то, что об этом может никто не узнать и считать что блок отрабатывает верно.
AN>>А у него такая задача не прерывать цепочку, чтобы не случилось.
S>Это весьма странно. Зачем нужна цепочка, которая не гарантирует результат?
Она как раз то и гарантирует требуемый результат.

AN>>>>>>Просто как более понятный пример
S>>>>>Вы его неверно трактуете.
AN>>>>Тут вопрос кто его неправильно трактует. Возможно мы его понимает по разному.
S>>>Вы его понимаете так, будто приложение должно делать то для чего оно написано, даже если данные повреждены.
AN>>А что бы вы предложили?
S>fail fast. В этом случае вы хотя бы узнаете, что нечто пошло не так и сможете сказать об этом пользователю, он обратится к вам и вы позже исправите ситуацию.
Как раз это и не требуется.
S>>>"поведение" вашего блока — нагнетать пургу и делать вид что все ок.
AN>>В данном случае задача формулируется так: если регулировщика переехала машина перекресток должен остаться регулируемым, пусть даже и строго в одном направлении.
S>Он не будет регулируемым, он будет регулируемым хаотически
Отчего? Данные или будут проходит правильные или нет.
AN>>Вполне возможно, что кто то может сказать блин — это ведь негуманно, давайте остановим движение и спасем регулировщика.
S>В вашем случае никто не узнает что что-то произошло и все будут делать вид что так и должно быть.
Именно в нашем случае это будет известно так как ожидаемые данные не получены.

Здравствуйте, hardcase, Вы писали:

H>Здравствуйте, AlexNek, Вы писали:

S>>>Ваш блок даже не выдает код ошибки, а просто гонит. Печально то, что об этом может никто не узнать и считать что блок отрабатывает верно.
AN>>А у него такая задача не прерывать цепочку, чтобы не случилось.

H>Запет на выброс исключений это совсем не картбланш на GI/GO (Garbage In — Garbage Out). Корректность входных данных проверять всеравно необходимо, и функция, которая не использует исключения для сигнализации, данных должна возвращать код результата (ошибки).
Чем возвращать код ошибки так уж лучше генерить исключение.
Это все весьма замечательно в теории, и я бы видимо тоже горячо об этом спорил.
Но что мне нужно делать при ошибке — не идти дальше. А вот это и заключается проблема что нужно пойти дальше не отклоняясь от пути.
Если красной шапочке не дали пирожков ей надо все равно идти, а не кричать где мои пирожки, иначе у бабушки будет инфаркт, от того что шапочка не пришла вовремя

Здравствуйте, AlexNek, Вы писали:

AN>Чем возвращать код ошибки так уж лучше генерить исключение.
AN>Это все весьма замечательно в теории, и я бы видимо тоже горячо об этом спорил.

WinAPI как-то ведь работает? А там нет исключений — сплошные коды возвратов.

AN>Но что мне нужно делать при ошибке — не идти дальше. А вот это и заключается проблема что нужно пойти дальше не отклоняясь от пути.

А вот это должен решать код, который вызывает функцию. Т.е. обрабатывать код возврата.

Здравствуйте, hardcase, Вы писали:

H>Здравствуйте, AlexNek, Вы писали:

AN>>Чем возвращать код ошибки так уж лучше генерить исключение.
AN>>Это все весьма замечательно в теории, и я бы видимо тоже горячо об этом спорил.

H>WinAPI как-то ведь работает? А там нет исключений — сплошные коды возвратов.
Я вообще то немного другое имел в виду.
Но можно пойти и по этому пути. А нафига тогда сделали исключения если и с кодом возврата было все так замечательно?

AN>>Но что мне нужно делать при ошибке — не идти дальше. А вот это и заключается проблема что нужно пойти дальше не отклоняясь от пути.

H>А вот это должен решать код, который вызывает функцию. Т.е. обрабатывать код возврата.
Иначе говоря всегда игнорировать код возврата. А потом, еще, в случае ошибки генерировать "нулевые данные" и идти дальше? Если бы фукнция входила в состав библиотеки для общего применения возможно именно так и поступили.

Здравствуйте, AlexNek, Вы писали:

AN>Здравствуйте, samius, Вы писали:

S>>Исключения бывают ожидаемыми и обрабатываемыми. Недостаточно данных для работы — нужно сказать пользователю что их недостаточно для работы. Не обязательно при этом делать вид что все работает, или показывать диалог с аварийным завершением.
AN>То бишь функцию лучше обвернуть в тру/сатч который нифига не делает?
Это еще хуже, чем у вас сейчас. И я такого не предлагал.

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

S>>fail fast. В этом случае вы хотя бы узнаете, что нечто пошло не так и сможете сказать об этом пользователю, он обратится к вам и вы позже исправите ситуацию.
AN>Как раз это и не требуется.
На моей старой работе была ситуация, когда программа готовилась на выставку, и там надо было гарантировать что никто не узнает, что программа не работает как это от нее ждут

S>>Он не будет регулируемым, он будет регулируемым хаотически
AN>Отчего? Данные или будут проходит правильные или нет.
Нет, они будут приходить либо правдоподобные либо нет. Гарантировать корректность правдоподобных данных никто не будет.

S>>В вашем случае никто не узнает что что-то произошло и все будут делать вид что так и должно быть.
AN>Именно в нашем случае это будет известно так как ожидаемые данные не получены.
Почему? Вы их получите, но не будете знать, то ли это, что хотели отправить.

Здравствуйте, AlexNek, Вы писали:

AN>Но можно пойти и по этому пути. А нафига тогда сделали исключения если и с кодом возврата было все так замечательно?
Нафига: что бы не анализировать коды возврата после каждого вызова

H>>А вот это должен решать код, который вызывает функцию. Т.е. обрабатывать код возврата.
AN>Иначе говоря всегда игнорировать код возврата. А потом, еще, в случае ошибки генерировать "нулевые данные" и идти дальше? Если бы фукнция входила в состав библиотеки для общего применения возможно именно так и поступили.
"нулевые данные" это уже какая-то гарантия что не будут отправлены ошибочные данные.

Здравствуйте, samius, Вы писали:

S>Здравствуйте, AlexNek, Вы писали:

AN>>Но можно пойти и по этому пути. А нафига тогда сделали исключения если и с кодом возврата было все так замечательно?
S>Нафига: что бы не анализировать коды возврата после каждого вызова
Думаю что не только, но думаю вы также согласны что исключение немного получше чем код возрата.

H>>>А вот это должен решать код, который вызывает функцию. Т.е. обрабатывать код возврата.
AN>>Иначе говоря всегда игнорировать код возврата. А потом, еще, в случае ошибки генерировать "нулевые данные" и идти дальше? Если бы фукнция входила в состав библиотеки для общего применения возможно именно так и поступили.
S>"нулевые данные" это уже какая-то гарантия что не будут отправлены ошибочные данные.
А что по вашему делает тогда функция, как не геренерит "нулевые данные" по ошибке.

Здравствуйте, samius, Вы писали:

S>Здравствуйте, AlexNek, Вы писали:

AN>>Здравствуйте, samius, Вы писали:

S>>>Исключения бывают ожидаемыми и обрабатываемыми. Недостаточно данных для работы — нужно сказать пользователю что их недостаточно для работы. Не обязательно при этом делать вид что все работает, или показывать диалог с аварийным завершением.
AN>>То бишь функцию лучше обвернуть в тру/сатч который нифига не делает?
S>Это еще хуже, чем у вас сейчас. И я такого не предлагал.
А что вы предлагаете?

AN>>Любой "пользователь" об этом узнает.
AN>>Если расматривать реального пользователя, то он оправляет некую команду на выполнение, а в результате получает сообщение, что команда выполнилась неправильно (так как ожидаемые данные не были получены). Если расмматривать пользователя- приемника информации, то он получает даже больше чем нужно. Он получает всего лишь один байт, что невозможно. Поэтому он знает что была просто неверная передача, а не то что клиент свалил.
S>В вашем случае реальна ситуация когда команда уходит неверная, ответ приходит неверный, но все довольны, потому как делали вид что все нормально.
Кто сказал, что такой подход используется повсеместно?

S>>>fail fast. В этом случае вы хотя бы узнаете, что нечто пошло не так и сможете сказать об этом пользователю, он обратится к вам и вы позже исправите ситуацию.
AN>>Как раз это и не требуется.
S>На моей старой работе была ситуация, когда программа готовилась на выставку, и там надо было гарантировать что никто не узнает, что программа не работает как это от нее ждут
В данном случае ситуация несколько другая. При неверных данных входные данных надо выдавать так называеты "нулевые данные", что в принципе и является кодом ошибки.

S>>>Он не будет регулируемым, он будет регулируемым хаотически
AN>>Отчего? Данные или будут проходит правильные или нет.
S>Нет, они будут приходить либо правдоподобные либо нет. Гарантировать корректность правдоподобных данных никто не будет.
В любом случае мы имеет три детерминированные ситуации:
— на входе правильные данные, на выходе правильные
— на входе правильные данные, на выходе "нулевые"
— на входе неправильные данные, на выходе "нулевые"
где проблема?

S>>>В вашем случае никто не узнает что что-то произошло и все будут делать вид что так и должно быть.
AN>>Именно в нашем случае это будет известно так как ожидаемые данные не получены.
S>Почему? Вы их получите, но не будете знать, то ли это, что хотели отправить.
А пому мы их получим, если команда на отправку не получена. Если даже что то и прийдет, то это должно быть не что то, а конкретный ответ на конкретную коамнду.

Здравствуйте, AlexNek, Вы писали:

AN>Здравствуйте, samius, Вы писали:

S>>Нафига: что бы не анализировать коды возврата после каждого вызова
AN>Думаю что не только, но думаю вы также согласны что исключение немного получше чем код возрата.
Не согласен. В разных случаях по разному. Но глотать проблему — совершенно точно не выход.

S>>"нулевые данные" это уже какая-то гарантия что не будут отправлены ошибочные данные.
AN>А что по вашему делает тогда функция, как не геренерит "нулевые данные" по ошибке.
Версия Sinclair-а кидается исключениями. Ваша — глотает ошибку. Ну или покажите мне, где эта генерация "нулевых данных".

Здравствуйте, AlexNek, Вы писали:

AN>Здравствуйте, samius, Вы писали:

S>>Это еще хуже, чем у вас сейчас. И я такого не предлагал.
AN>А что вы предлагаете?
Предлагаю не замалчивать проблему.

S>>В вашем случае реальна ситуация когда команда уходит неверная, ответ приходит неверный, но все довольны, потому как делали вид что все нормально.
AN>Кто сказал, что такой подход используется повсеместно?
Я проэкстраполировал ваше отношение к исключениям вместе с примерами распознавания. Уверен, что не ошибся.

AN>В данном случае ситуация несколько другая. При неверных данных входные данных надо выдавать так называеты "нулевые данные", что в принципе и является кодом ошибки.
Т.е. вместо того чтобы кто-то анализировал код ошибки, он должен разобрать данные и понять что они неверные? Но эти данные ведь не возвращаются вызывающему коду!

AN>В любом случае мы имеет три детерминированные ситуации:
AN>- на входе правильные данные, на выходе правильные
AN>- на входе правильные данные, на выходе "нулевые"
AN>- на входе неправильные данные, на выходе "нулевые"
AN>где проблема?
Проблема в том что нет кода, отличающего правильные от неправильных. Ваш передает любые данные после некоторой модификации.

S>>Почему? Вы их получите, но не будете знать, то ли это, что хотели отправить.
AN>А пому мы их получим, если команда на отправку не получена. Если даже что то и прийдет, то это должно быть не что то, а конкретный ответ на конкретную коамнду.
Конкретный искаженный ошибкой ответ на конкретную искаженную ошибкой команду. Вы уверены, что это то чего вы ожидаете от программы? Откуда будет уверенность что получили ответ на то что посылали вообще?

Здравствуйте, samius, Вы писали:

S>Здравствуйте, AlexNek, Вы писали:

AN>>Здравствуйте, samius, Вы писали:

S>>>Нафига: что бы не анализировать коды возврата после каждого вызова
AN>>Думаю что не только, но думаю вы также согласны что исключение немного получше чем код возрата.
S>Не согласен. В разных случаях по разному. Но глотать проблему — совершенно точно не выход.
Для чего нужны разные случаи, почему нельзя все сделлать единообразно?
S>>>"нулевые данные" это уже какая-то гарантия что не будут отправлены ошибочные данные.
AN>>А что по вашему делает тогда функция, как не геренерит "нулевые данные" по ошибке.
S>Версия Sinclair-а кидается исключениями. Ваша — глотает ошибку. Ну или покажите мне, где эта генерация "нулевых данных".
Не имею понятия как это показать.
Но буфер должен быть либо нуль, либо содержать только префикс

Здравствуйте, samius, Вы писали:

S>Здравствуйте, AlexNek, Вы писали:

AN>>Здравствуйте, samius, Вы писали:

S>>>Это еще хуже, чем у вас сейчас. И я такого не предлагал.
AN>>А что вы предлагаете?
S>Предлагаю не замалчивать проблему.
Ок, кричим, что дальше?

S>>>В вашем случае реальна ситуация когда команда уходит неверная, ответ приходит неверный, но все довольны, потому как делали вид что все нормально.
AN>>Кто сказал, что такой подход используется повсеместно?
S>Я проэкстраполировал ваше отношение к исключениям вместе с примерами распознавания. Уверен, что не ошибся.
Блин, прийдется убирать модуль обработки ошибок

AN>>В данном случае ситуация несколько другая. При неверных данных входные данных надо выдавать так называеты "нулевые данные", что в принципе и является кодом ошибки.
S>Т.е. вместо того чтобы кто-то анализировал код ошибки, он должен разобрать данные и понять что они неверные? Но эти данные ведь не возвращаются вызывающему коду!
Я же говорил о цепочке. Цепочка или вся работает или нет. Модуль стоящий в начале цепочки спокойно все и определяет

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

S>>>Почему? Вы их получите, но не будете знать, то ли это, что хотели отправить.
AN>>А пому мы их получим, если команда на отправку не получена. Если даже что то и прийдет, то это должно быть не что то, а конкретный ответ на конкретную коамнду.
S>Конкретный искаженный ошибкой ответ на конкретную искаженную ошибкой команду. Вы уверены, что это то чего вы ожидаете от программы? Откуда будет уверенность что получили ответ на то что посылали вообще?>
То есть две ошибки сразу?
Команда не может исказится в данном методе. По крайней мере, я не вижу этого.

Здравствуйте, AlexNek, Вы писали:

AN>Здравствуйте, samius, Вы писали:

S>>Предлагаю не замалчивать проблему.
AN>Ок, кричим, что дальше?
реагируем

AN>>>Кто сказал, что такой подход используется повсеместно?
S>>Я проэкстраполировал ваше отношение к исключениям вместе с примерами распознавания. Уверен, что не ошибся.
AN>Блин, прийдется убирать модуль обработки ошибок
Занятно! Т.е. у вас есть модули которые ошибки прячут, и есть которые их спрятанные обрабатывают?
Это игра в "мафию" в одну каску

AN>Я же говорил о цепочке. Цепочка или вся работает или нет. Модуль стоящий в начале цепочки спокойно все и определяет
Он даже не может определить, ушли ли от него верные данные

AN>его задача просто ретранслировать данные если он не может этого сделать генерируются "нулевые данные"
По-моему пора завязывать.

S>>Конкретный искаженный ошибкой ответ на конкретную искаженную ошибкой команду. Вы уверены, что это то чего вы ожидаете от программы? Откуда будет уверенность что получили ответ на то что посылали вообще?>
AN>То есть две ошибки сразу?
AN>Команда не может исказится в данном методе. По крайней мере, я не вижу этого.
Вы исходите из того что весь код написан верно. Это работает только в том случае, если весь код написан верно. Если что-то неверно, то ошибка размазывается по всей цепочке, т.е. никаких данных о том, на каком этапе возникла ошибка у вас нет. Есть только "нулевые" данные на выходе.
В общем, успехов в отладке!

Здравствуйте, AlexNek, Вы писали:

AN>Здравствуйте, samius, Вы писали:

S>>Здравствуйте, AlexNek, Вы писали:

AN>>>Здравствуйте, samius, Вы писали:

S>>>>Нафига: что бы не анализировать коды возврата после каждого вызова
AN>>>Думаю что не только, но думаю вы также согласны что исключение немного получше чем код возрата.
S>>Не согласен. В разных случаях по разному. Но глотать проблему — совершенно точно не выход.
AN>Для чего нужны разные случаи, почему нельзя все сделлать единообразно?
Разные случаи не нужны, они есть. В них либо может быть ситуация не исключительная, тогда код возврата.
Dictionary.TryGetValue — отсутствие ключа — исключительная ситуация, отсутствие записи — штатная с кодом возврата.
В других исключений избегают по соображениям производительности.

S>>>>"нулевые данные" это уже какая-то гарантия что не будут отправлены ошибочные данные.
AN>>>А что по вашему делает тогда функция, как не геренерит "нулевые данные" по ошибке.
S>>Версия Sinclair-а кидается исключениями. Ваша — глотает ошибку. Ну или покажите мне, где эта генерация "нулевых данных".
AN>Не имею понятия как это показать.
AN>Но буфер должен быть либо нуль, либо содержать только префикс
В оригинальном коде никакого анализа нет на эту тему. Приходят рассогласованные данные на вход и результат сложно предсказать.