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

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

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

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

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

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

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

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

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

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

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

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

 value
    Type: TValue

When this method returns, contains the value associated with the specified key, if the key is found; otherwise, the default value for the type of the value parameter. This parameter is passed uninitialized.


То именно так и делается

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

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

S>>реагируем
AN>Каким образом?
Fail Fast!
AN>Скажем так, ранее этой функции не было и не планировалось. Потом понадобилась, соотвественно ничего нарушать она не должна.
Если она понадобилась, значит что-то она должна делать и делать это корректно. Если это не так, то лучше ее выкинуть нафик.

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

S>>По-моему пора завязывать.
AN>Как есть желание.
Есть желание завязывать

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

S>>В общем, успехов в отладке!
AN>Понимаю Вашу иронию, но не все так плохо как вам кажется.

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

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

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

AN> value
AN>    Type: TValue

AN>

When this method returns, contains the value associated with the specified key, if the key is found; otherwise, the default value for the type of the value parameter. This parameter is passed uninitialized.

AN>То именно так и делается
Нет. В случае TryGetValue у вызывающего кода есть возможность узнать что
а) данные переданы корректно
б) указанный ключ зарегистрирован (или нет)

В вашем случае вызывающий код не знает ничего о том, правильно ли он подал данные. положит он 10000 в bufferLength и для него ничего не изменится.

AN>Результат сложно предсказать потому, что код хреново написан, именно поэтому и тему сделал. Смотришь в код и нифига не видишь
Это я заметил. Так же как и то, что к вызываемому коду не предъявляется никаких требований. А значит вызывать этот метод могут как угодно.

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

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

S>>>реагируем
AN>>Каким образом?
S>Fail Fast!
Тогда приходим к примеру с OCR
AN>>Скажем так, ранее этой функции не было и не планировалось. Потом понадобилась, соотвественно ничего нарушать она не должна.
S>Если она понадобилась, значит что-то она должна делать и делать это корректно. Если это не так, то лучше ее выкинуть нафик.
Так она и делает это корректно.

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

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

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

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

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

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

AN>> value
AN>>    Type: TValue

AN>>

When this method returns, contains the value associated with the specified key, if the key is found; otherwise, the default value for the type of the value parameter. This parameter is passed uninitialized.

AN>>То именно так и делается
S>Нет. В случае TryGetValue у вызывающего кода есть возможность узнать что
S>а) данные переданы корректно
Куда переданны?
S>б) указанный ключ зарегистрирован (или нет)

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

AN>>Результат сложно предсказать потому, что код хреново написан, именно поэтому и тему сделал. Смотришь в код и нифига не видишь
S>Это я заметил. Так же как и то, что к вызываемому коду не предъявляется никаких требований. А значит вызывать этот метод могут как угодно.
Требования есть (не давать непраыильных данных ), но считается, что вызывающий код способен на любую подлость.

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

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

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

S>>Fail Fast!
AN>Тогда приходим к примеру с OCR
отвечу в следующем сообщении

S>>Есть желание завязывать
AN>Тогда приятного вечера, хороших выходных и большое спасибо
Принимаю

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

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

S>>Нет. В случае TryGetValue у вызывающего кода есть возможность узнать что
S>>а) данные переданы корректно
AN>Куда переданны?
В метод TryGetValue
S>>б) указанный ключ зарегистрирован (или нет)

К вопросу об OCR. Вы обсжуждаете вариант, при котором в данных не может быть распознан некий символ. Я обсуждаю вариант, при котором данные не пригодны для анализа. Вернемся к tryGetValue:
а) то что не выскочило исключение из этого метода говорит о том, что данные ему переданы корректно, что там не null!
б) код возврата говорит о том, нашлась запись по ключу или нет.
В вашем случае ничего не говорит ни о том ни о другом.

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

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

Представьте, что TryGetValue возвращает true если ему передали null в качестве ключа. Будет ли это гуманно?

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

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

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

S>>>Нет. В случае TryGetValue у вызывающего кода есть возможность узнать что
S>>>а) данные переданы корректно
AN>>Куда переданны?
S>В метод TryGetValue
S>>>б) указанный ключ зарегистрирован (или нет)

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

S>Вернемся к tryGetValue:
S>а) то что не выскочило исключение из этого метода говорит о том, что данные ему переданы корректно, что там не null!
S>б) код возврата говорит о том, нашлась запись по ключу или нет.
А где там есть код возврата? Это задача функции сказать есть там данные или нет.
S>В вашем случае ничего не говорит ни о том ни о другом.
А это от нее и не требуется. Функция не является методом "спросил ответил". Есть некий поток данных и она просто вклинивается внутрь. Метод уже передал данные дальше, что будет с ними дальше его уже не волнует. Но если он выдает ошибочные данные их весьма нежелательно передавать дальше. Поэтому у этой функции как бы два "официальных" задания: преобразовать данные, в случае невозможности преобразования выдать "нулевые данные". Согласен, что нехорошо давать одной функции два задания, но иначе интерфейс был бы слишком запутанный.

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

S>>>Это я заметил. Так же как и то, что к вызываемому коду не предъявляется никаких требований. А значит вызывать этот метод могут как угодно.
AN>>Требования есть (не давать непраыильных данных ), но считается, что вызывающий код способен на любую подлость.
S>Подлость — это вызываемому коду не отвечать на другую подлость.
А ему такое задание дали улаживать конфликты.

S>Представьте, что TryGetValue возвращает true если ему передали null в качестве ключа. Будет ли это гуманно?
Это меняеет описание поведения функции. null можно рассматривать как эквивалент всегда неверного ключа, так как null в качестве ключа не разрешен, поэтому возврат false был бы более гуманным методом.

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

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

Неправильно понимаете. Обработка исключения и будет сводиться к показу пустой страницы с текстом, что невозможно проанализировать данные.

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

h> S>>К вопросу об OCR. Вы обсжуждаете вариант, при котором в данных не может быть распознан некий символ. Я обсуждаю вариант, при котором данные не пригодны для анализа.

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

h> Неправильно понимаете. Обработка исключения и будет сводиться к показу пустой страницы с текстом, что невозможно проанализировать данные.
Логика получается слишком сложная, которую сложно развивать. Не говоря о том что модуль отображения находится в километре от приема. Если исключения возникают в модуле приема "по внутренним причинам", то в этом случае страница, не показывается — это ошибка модуля ее нужно показать и обработать как ошибку. Если же просто ошибка приема данных, то тут показываем страницу с пометкой.
(Хотя пожалуй, можно сделать базовый класс для ошибок приема)

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

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

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

S>>Вернемся к tryGetValue:
S>>а) то что не выскочило исключение из этого метода говорит о том, что данные ему переданы корректно, что там не null!
S>>б) код возврата говорит о том, нашлась запись по ключу или нет.
AN>А где там есть код возврата? Это задача функции сказать есть там данные или нет.
Не путайте с ContainsKey. Задача TryGetValue — достать значение. Возвращенный bool — это код возврата.

S>>В вашем случае ничего не говорит ни о том ни о другом.
AN>А это от нее и не требуется. Функция не является методом "спросил ответил". Есть некий поток данных и она просто вклинивается внутрь. Метод уже передал данные дальше, что будет с ними дальше его уже не волнует. Но если он выдает ошибочные данные их весьма нежелательно передавать дальше. Поэтому у этой функции как бы два "официальных" задания: преобразовать данные, в случае невозможности преобразования выдать "нулевые данные". Согласен, что нехорошо давать одной функции два задания, но иначе интерфейс был бы слишком запутанный.
Эта техника способствует сокрытию ошибок вместо их исправления

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

S>>Подлость — это вызываемому коду не отвечать на другую подлость.
AN>А ему такое задание дали улаживать конфликты.
Он их не улаживает, он их заметает под ковер

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

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

s> S>>К вопросу об OCR. Вы обсжуждаете вариант, при котором в данных не может быть распознан некий символ. Я обсуждаю вариант, при котором данные не пригодны для анализа.

s> AN>В этом случае также ничего не надо делать, а показать пустую страницу, с текстом что невозможно проанализировать данные.

s> И что мешает?
система обработки ошибок
s> AN>В случае исключения надо было не показывать страницу вообще, а выдать сообщение об ошибке.

s> Это предубеждение. Вы понаблюдайте за программами на компьютере, ниужели ваша аська показывает сообщение об ошибке при обрыве связи?
Так именно об этом я и говорю. Нужно иметь отличие ошибки и ошибочной ситуации.
s> S>>Вернемся к tryGetValue:
s> S>>а) то что не выскочило исключение из этого метода говорит о том, что данные ему переданы корректно, что там не null!
s> S>>б) код возврата говорит о том, нашлась запись по ключу или нет.

s> AN>А где там есть код возврата? Это задача функции сказать есть там данные или нет.

s> Не путайте с ContainsKey. Задача TryGetValue — достать значение. Возвращенный bool — это код возврата.
Странно, говорят немного о другом

Return Value
Type: System.Boolean
true if the Dictionary<TKey, TValue> contains an element with the specified key; otherwise, false.

s> S>>В вашем случае ничего не говорит ни о том ни о другом.

s> AN>А это от нее и не требуется. Функция не является методом "спросил ответил". Есть некий поток данных и она просто вклинивается внутрь. Метод уже передал данные дальше, что будет с ними дальше его уже не волнует. Но если он выдает ошибочные данные их весьма нежелательно передавать дальше. Поэтому у этой функции как бы два "официальных" задания: преобразовать данные, в случае невозможности преобразования выдать "нулевые данные". Согласен, что нехорошо давать одной функции два задания, но иначе интерфейс был бы слишком запутанный.

s> Эта техника способствует сокрытию ошибок вместо их исправления
Не призываю применять ее повсеместно и не утверждаю что это хорошо.

s> AN>>>А ему это и не требуется знать. Задача модуля выстоять до последенего патрона. А не докладывать обстановку наверх после каждого вражеского выстрела.

s> S>>В данном случае он будет стрелять по своим

s> AN>Не будет, уже проверяли

s> Откуда такая уверенность? Ваша программа больше не модифицируется?
Данный модуль не планируется никак модифицировать.

s> S>>Подлость — это вызываемому коду не отвечать на другую подлость.

s> AN>А ему такое задание дали улаживать конфликты.

s> Он их не улаживает, он их заметает под ковер

s> S>>Представьте, что TryGetValue возвращает true если ему передали null в качестве ключа. Будет ли это гуманно?

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

s> На самом деле столь же гуманным как и true, потому как у вызывающего кода нет возможности понять, как именно трактовать результат, как признак нарушения контракта, либо как признак наличия/отсутствия данных. Что бы разобраться с этим вопросом на стороне вызывающего кода, придется продублировать проверку данных и следить что бы она совпадала с той, что на стороне вызываемого кода.
Тут нужно спросить а надо ли нам трактовать результат?
Давайте попросим код ошибки от Console.WriteLine и будем извещать пользователя если что не так

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

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

s>> И что мешает?
AN>система обработки ошибок
Что-то не так с вашей системой

AN>Так именно об этом я и говорю. Нужно иметь отличие ошибки и ошибочной ситуации.
Дык у вас и то и другое ничем не отличается от нормы

s>> Не путайте с ContainsKey. Задача TryGetValue — достать значение. Возвращенный bool — это код возврата.
AN>Странно, говорят немного о другом
AN>

Return Value
AN>Type: System.Boolean
AN>true if the Dictionary<TKey, TValue> contains an element with the specified key; otherwise, false.
AN>

О чем о другом? О том что нужно использовать TryGetValue вместо ContainsKey, или о том что возвращаемое значение не является кодом возврата? Я ничего такого не вижу.

s>> Откуда такая уверенность? Ваша программа больше не модифицируется?
AN>Данный модуль не планируется никак модифицировать.
Да же в случае если завтра в нем будет обнаружен баг?

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

AN>Давайте попросим код ошибки от Console.WriteLine и будем извещать пользователя если что не так
Будьте уверены, что если что не так, то из WriteLine вылетит исключение, которое даст знать, что именно не так. WriteLine как раз не будет делать вид что все "так".

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

s> s>> И что мешает?

s> AN>система обработки ошибок

s> Что-то не так с вашей системой
Что именно?
Если она получает ошибку то для всех ошибок у нее есть стандартное действие, как миниму показать ошибку.

s> AN>Так именно об этом я и говорю. Нужно иметь отличие ошибки и ошибочной ситуации.

s> Дык у вас и то и другое ничем не отличается от нормы
откуда такая уверенность?

s> s>> Не путайте с ContainsKey. Задача TryGetValue — достать значение. Возвращенный bool — это код возврата.

s> AN>Странно, говорят немного о другом
s> AN>

Return Value
s> AN>Type: System.Boolean
s> AN>true if the Dictionary<TKey, TValue> contains an element with the specified key; otherwise, false.
s> AN>

s> О чем о другом? О том что нужно использовать TryGetValue вместо ContainsKey, или о том что возвращаемое значение не является кодом возврата? Я ничего такого не вижу.

что возвращаемое значение не является кодом возврата

s> s>> Откуда такая уверенность? Ваша программа больше не модифицируется?

s> AN>Данный модуль не планируется никак модифицировать.

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

s> s>> На самом деле столь же гуманным как и true, потому как у вызывающего кода нет возможности понять, как именно трактовать результат, как признак нарушения контракта, либо как признак наличия/отсутствия данных. Что бы разобраться с этим вопросом на стороне вызывающего кода, придется продублировать проверку данных и следить что бы она совпадала с той, что на стороне вызываемого кода.

s> AN>Тут нужно спросить а надо ли нам трактовать результат?

s> Я уже понял, что вам не надо. Именно против этого и выступаю.
Я только хочу сказать, что это не всегда нужно. Если бы функция была бы в библиотеке для прямого использования подписался бы под Вашими словами на все 100%.

s> AN>Давайте попросим код ошибки от Console.WriteLine и будем извещать пользователя если что не так

s> Будьте уверены, что если что не так, то из WriteLine вылетит исключение, которое даст знать, что именно не так. WriteLine как раз не будет делать вид что все "так".
А отчего микрософт не рекомендует его ловить, а делает так?

            try {
                billTotal = Double.Parse(args[0]);
            }
            catch(FormatException) {
                Console.WriteLine("usage: TIPCALC total");
                return 1;
            }

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

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

s>> AN>система обработки ошибок

s>> Что-то не так с вашей системой
AN>Что именно?
AN>Если она получает ошибку то для всех ошибок у нее есть стандартное действие, как миниму показать ошибку.
То что она не предоставляет гибкость

s>> AN>Так именно об этом я и говорю. Нужно иметь отличие ошибки и ошибочной ситуации.

s>> Дык у вас и то и другое ничем не отличается от нормы
AN>откуда такая уверенность?
из вашего кода

s>> О чем о другом? О том что нужно использовать TryGetValue вместо ContainsKey, или о том что возвращаемое значение не является кодом возврата? Я ничего такого не вижу.

AN>что возвращаемое значение не является кодом возврата
Там такого не написано

s>> AN>Данный модуль не планируется никак модифицировать.
s>> Да же в случае если завтра в нем будет обнаружен баг?
AN>Вероятность довольно низкая, за несколько лет использования там практически не было исправлений.
И что будете делать при обнаружении бага или изменении требований? Считать вероятность или исправлять?

s>> Я уже понял, что вам не надо. Именно против этого и выступаю.
AN>Я только хочу сказать, что это не всегда нужно. Если бы функция была бы в библиотеке для прямого использования подписался бы под Вашими словами на все 100%.
Пусть не всегда. Но веские причины все-же не названы. Отсылка к OCR здесь ложная, т.к. ситуация другая.

s>> Будьте уверены, что если что не так, то из WriteLine вылетит исключение, которое даст знать, что именно не так. WriteLine как раз не будет делать вид что все "так".
AN>А отчего микрософт не рекомендует его ловить, а делает так?
Вопрос с подвохом. Покажите мне для начала то место где микрософт не рекомендует ловить исключения WriteLine.
Как считаете, для чего дан перечень исключений методов WriteLine, разве для того что бы их не ловили?
AN>

            try {
AN>                billTotal = Double.Parse(args[0]);
AN>            }
AN>            catch(FormatException) {
AN>                Console.WriteLine("usage: TIPCALC total");
AN>                return 1;
AN>            }
AN>

Показать вам код, который вышибет исключение из процитированного примера ровно в строчке WriteLine?

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

s> s>> AN>система обработки ошибок

s> s>> Что-то не так с вашей системой

s> AN>Что именно?
s> AN>Если она получает ошибку то для всех ошибок у нее есть стандартное действие, как миниму показать ошибку.

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

s> s>> AN>Так именно об этом я и говорю. Нужно иметь отличие ошибки и ошибочной ситуации.

s> s>> Дык у вас и то и другое ничем не отличается от нормы

s> AN>откуда такая уверенность?

s> из вашего кода
Во первых, код не мой, а во вторых это всего лишь маленькая часть.

s> s>> О чем о другом? О том что нужно использовать TryGetValue вместо ContainsKey, или о том что возвращаемое значение не является кодом возврата? Я ничего такого не вижу.

s> AN>что возвращаемое значение не является кодом возврата

s> Там такого не написано
В противном случае там бы стояло, в случае ошибки.....
И сравните описание возврата:
-здесь
-здесь

s> s>> AN>Данный модуль не планируется никак модифицировать.

s> s>> Да же в случае если завтра в нем будет обнаружен баг?

s> AN>Вероятность довольно низкая, за несколько лет использования там практически не было исправлений.

s> И что будете делать при обнаружении бага или изменении требований? Считать вероятность или исправлять?
безусловно править ограниченную часть кода, например, данному программисту было разрешено менять исключительно только данную функцию.

s> s>> Я уже понял, что вам не надо. Именно против этого и выступаю.

s> AN>Я только хочу сказать, что это не всегда нужно. Если бы функция была бы в библиотеке для прямого использования подписался бы под Вашими словами на все 100%.

s> Пусть не всегда. Но веские причины все-же не названы. Отсылка к OCR здесь ложная, т.к. ситуация другая.
Как раз именно абсолютно такая же, считайте что данная часть модуля подает команды на сканирование документа.

s> s>> Будьте уверены, что если что не так, то из WriteLine вылетит исключение, которое даст знать, что именно не так. WriteLine как раз не будет делать вид что все "так".

s> AN>А отчего микрософт не рекомендует его ловить, а делает так?

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

s> Как считаете, для чего дан перечень исключений методов WriteLine, разве для того что бы их не ловили?
Ок давайте будем ловить. Понравилось?

            try {
                billTotal = Double.Parse(args[0]);
            }
            catch(FormatException) {
                try
                {
                    Console.WriteLine("usage: TIPCALC total");
                }
                catch (IOException ex)
                {
                    MessageBox.Show("Kirdyk 1");
                }
                return 1;
            }

            try
            {
               Console.WriteLine();
            }
            catch (IOException ex)
            {
                MessageBox.Show("Kirdyk 2");
            }

            try
            {
               Console.WriteLine("Bill total:\t{0,8:c}", billTotal);
            }
            catch (IOException ex)
            {
                MessageBox.Show("Kirdyk 3");
            }

s> Показать вам код, который вышибет исключение из процитированного примера ровно в строчке WriteLine?
И что даст это исключение для пользователя, в данном случае?

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

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

s>> То что она не предоставляет гибкость
AN>Тогда это будет уже совсем другая система, даже точнее не система а монстрик
AN>- она должна иметь множество путей обработки ошибок
AN>- она должна различать определенные ошибки и выбирать требуемый путь.
AN>- она должна знать что конкретно делать при каждом пути.
AN>- она должна располагаться на многих уровнях и иметь доступ к данным ее не касающихся.
Не знаю, что у вас за особенная система, но все перечисленное (кроме доступа к не касающимся данным) можно обеспечить грамотным использованием try/catch конструкций и глобальными обработчиками.

s>> s>> Дык у вас и то и другое ничем не отличается от нормы

s>> AN>откуда такая уверенность?

s>> из вашего кода
AN>Во первых, код не мой, а во вторых это всего лишь маленькая часть.
Вижу, по выделенному возражений нет, кроме вопроса принадлежности кода?

s>> AN>что возвращаемое значение не является кодом возврата

s>> Там такого не написано
AN>В противном случае там бы стояло, в случае ошибки.....
AN>И сравните описание возврата:
AN>-здесь
AN>-здесь
Походу вы собираетесь и дальше препираться на тему можно ли трактовать результат TryGetValue кодом возврата, вместо того что бы согласиться что TryGetValue позволяет разобраться как с корректностью аргумента, так и с наличием записи?
Давайте назовем результат TryGetValue вместо кода возврата признаком успеха. Это изменит суть претензий?

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

s>> Пусть не всегда. Но веские причины все-же не названы. Отсылка к OCR здесь ложная, т.к. ситуация другая.
AN>Как раз именно абсолютно такая же, считайте что данная часть модуля подает команды на сканирование документа.
Битая команда и нераспознаный в корректных данных символ — это весьма далекие ситуации.

s>> AN>А отчего микрософт не рекомендует его ловить, а делает так?

s>> Вопрос с подвохом. Покажите мне для начала то место где микрософт не рекомендует ловить исключения WriteLine.
AN>Подобные вещи обычно находятся в коде, на такие мелочи они не размениваются.
Т.е. микрософту вы приписали тезисы вашей фантазии, разыгравшейся на почве примеров MSDN?

s>> Как считаете, для чего дан перечень исключений методов WriteLine, разве для того что бы их не ловили?
AN>Ок давайте будем ловить. Понравилось?

AN>

AN>

Я чувствую что этим безграмотным примером вы хотели ввести меня в какие-то противоречия, а не показать свое умение работы с исключениями. Потому комментировать его не буду. Но так же вижу, что у вас нет ответа на вопрос, зачем перечень исключений WriteLine представлен в MSDN...

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

Вернемся к посылу

Давайте попросим код ошибки от Console.WriteLine и будем извещать пользователя если что не так

Механизм исключений для того и предназначен, что бы извещать пользователя, разработчика, или еще кого. Но делает это он именно на том уровне, где стоят обработчики. Тыкать обработчики на каждый вызов — не очень умно. Только не говорите что в примерах MSDN на try/catch делается именно так Все примеры MSDN рассчитаны на объем кода в две ладошки и не подразумевают продвинутых подходов к обработке исключений.

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

s> s>> То что она не предоставляет гибкость

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

s> Не знаю, что у вас за особенная система, но все перечисленное (кроме доступа к не касающимся данным) можно обеспечить грамотным использованием try/catch конструкций и глобальными обработчиками.
Ну это уже не система, а просто набор try/catch при этом нужен будет еще один определенный класс исключений "не обрабатывать" с указанием, что надо делать в этом случае.
s> s>> s>> Дык у вас и то и другое ничем не отличается от нормы

s> s>> AN>откуда такая уверенность?

s> s>> из вашего кода

s> AN>Во первых, код не мой, а во вторых это всего лишь маленькая часть.

s> Вижу, по выделенному возражений нет, кроме вопроса принадлежности кода?
Вы про "маленькую часть" еще забыли.

s> s>> AN>что возвращаемое значение не является кодом возврата

s> s>> Там такого не написано

s> AN>В противном случае там бы стояло, в случае ошибки.....
s> AN>И сравните описание возврата:
s> AN>-здесь
s> AN>-здесь

s> Походу вы собираетесь и дальше препираться на тему можно ли трактовать результат TryGetValue кодом возврата, вместо того что бы согласиться что TryGetValue позволяет разобраться как с корректностью аргумента, так и с наличием записи?
Про корректность аргументов там ничего не сказано.
Я только хочу сказать, что эти функции имеют другую задачу.
s> Давайте назовем результат TryGetValue вместо кода возврата признаком успеха. Это изменит суть претензий?
Ну если true и false считать признаками успеха, то да.

s> s>> И что будете делать при обнаружении бага или изменении требований? Считать вероятность или исправлять?

s> AN>безусловно править ограниченную часть кода, например, данному программисту было разрешено менять исключительно только данную функцию.

s> Меня не очень интересуют политики разрешения на изменение кода в вашей конторе. Но сам факт того что вы допускаете изменения, но не допускаете изменения поведения мне странен.
s> Возможно программист не внесет ломающих изменений, но если внесет, как вы их локализуете? Это повод для размышлений, мне отвечать не нужно.

s> s>> Пусть не всегда. Но веские причины все-же не названы. Отсылка к OCR здесь ложная, т.к. ситуация другая.

s> AN>Как раз именно абсолютно такая же, считайте что данная часть модуля подает команды на сканирование документа.

s> Битая команда и нераспознаный в корректных данных символ — это весьма далекие ситуации.
Из-за этой команды головка хреново синхронизировалась со сканером и символ/строку уже не распознать, их может просто не быть там.

s> s>> AN>А отчего микрософт не рекомендует его ловить, а делает так?

s> s>> Вопрос с подвохом. Покажите мне для начала то место где микрософт не рекомендует ловить исключения WriteLine.

s> AN>Подобные вещи обычно находятся в коде, на такие мелочи они не размениваются.

s> Т.е. микрософту вы приписали тезисы вашей фантазии, разыгравшейся на почве примеров MSDN?

s> s>> Как считаете, для чего дан перечень исключений методов WriteLine, разве для того что бы их не ловили?
вопрос в том что это даст практически?

s> AN>Ок давайте будем ловить. Понравилось?

s> AN>

s> AN>

s> Я чувствую что этим безграмотным примером вы хотели ввести меня в какие-то противоречия, а не показать свое умение работы с исключениями. Потому комментировать его не буду. Но так же вижу, что у вас нет ответа на вопрос, зачем перечень исключений WriteLine представлен в MSDN...

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

s> s>> Показать вам код, который вышибет исключение из процитированного примера ровно в строчке WriteLine?

s> AN>И что даст это исключение для пользователя, в данном случае?

s> Открою секрет, что ловля исключений подразумевает не только показ MessageBox-а пользователю. В частности, например, гашение исключения позволит коду работать дальше, невзирая на случившиеся проблемы.
То бишь вначале генерим то что нам не нужно, а после пытаемся это игнорировать.

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

s> Вернемся к посылу
s>

s> Давайте попросим код ошибки от Console.WriteLine и будем извещать пользователя если что не так

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

Понимаете, я не явлюсь противником использования исключений, а только хочу сказать, что их использование не подразумевает 100% покрытие. Нам нужна какая либо реакция на ошибку и не всегда нужно кричать об ошибке.
Ну типа выезжаю я на перекресток по главной улице и вижу машину которая также думает, что едет по главной. Да можно и посигналить и дождаться стражей порядка после аварии, но можно и просто притормозить. Конечно, в этом случае никто не узнает о нарушении. Но вопрос в том, что будет лучше в определенных ситуациях: кричать о нарушении или промолчать?

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

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

s>> Походу вы собираетесь и дальше препираться на тему можно ли трактовать результат TryGetValue кодом возврата, вместо того что бы согласиться что TryGetValue позволяет разобраться как с корректностью аргумента, так и с наличием записи?
AN>Про корректность аргументов там ничего не сказано.
см. секцию исключений

s>> Битая команда и нераспознаный в корректных данных символ — это весьма далекие ситуации.
AN>Из-за этой команды головка хреново синхронизировалась со сканером и символ/строку уже не распознать, их может просто не быть там.
Во! Из-за битой команды может пострадать результат сканирования, потому ситуации с битыми командами надо как минимум протоколировать и разбираться с ними, что бы максимально исключить возможность порчи данных команды.
Однако ситуация с нераспознаванием символа/строки может случиться и с валидной командой для головки, например из-за дефекта носителя. Это вообще норма, с этим ничего сделать нельзя, в этом софт не виноват и крайних искать не надо, так же как и исправлять что-либо. Т.е. одно может быть следствием другого, но не признаком другого.

s>> s>> Как считаете, для чего дан перечень исключений методов WriteLine, разве для того что бы их не ловили?
AN>вопрос в том что это даст практически?
Практически это дает контроль над исключениями, возникшими внутри WriteLine. Т.е. программист имеет возможность обрабатывать их согласно постановке задачи. Обычно это не требуется, но если взять тот же пример, когда работа не должна убиваться при ошибке вывода в консоль (IO или FormatException), программист может обработать эту ситуацию. В другом случае он не будет спеицальным образом обрабатывать эти исключения и получит FailFast, который позволит увидеть проблему на раннем этапе.

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

s>> AN>И что даст это исключение для пользователя, в данном случае?

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

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

s>> Механизм исключений для того и предназначен, что бы извещать пользователя, разработчика, или еще кого. Но делает это он именно на том уровне, где стоят обработчики. Тыкать обработчики на каждый вызов — не очень умно.
AN>А есть вариант "глобального гашения"?
Любое глобальное решение не подразумевает продолжение работы с места возбуждения без оборачивания кода в try/catch.

AN>Понимаете, я не явлюсь противником использования исключений, а только хочу сказать, что их использование не подразумевает 100% покрытие. Нам нужна какая либо реакция на ошибку и не всегда нужно кричать об ошибке.
Для начала надо научиться отличать ошибки в логике программы, от ошибок окружения, данных и т.п. О первых надо кричать, если только вы не хотите создать у пользователя впечатления о том что программа работает, когда она уже пошла в разнос.

AN>Ну типа выезжаю я на перекресток по главной улице и вижу машину которая также думает, что едет по главной. Да можно и посигналить и дождаться стражей порядка после аварии, но можно и просто притормозить. Конечно, в этом случае никто не узнает о нарушении. Но вопрос в том, что будет лучше в определенных ситуациях: кричать о нарушении или промолчать?
Не корректное сравнение. Обсуждаемая потенциальная ошибка с рассогласованием данных команды будет аналогична ситуации, когда вы выезжаете на перекресток, а реакцией на нажатие на тормоз будет эффектное открытие багажника. Если после вы захотите разобраться, отчего такой глюк произошел, у вас должна быть хоть какая-то информация. Я не настаиваю что это должна быть ажурная надпись на airbag-е, выскочившая в процессе экстренного маневрирования (аналог MessageBox-а). Но хоть что-то, с чем сервисмен разберется, подключив диагностическую колодку.