Здравствуйте, sergey_shandar, Вы писали:
s> AN>Что то часто мне стал попадаться код в который сразу не врубишься, при этом код делает свою задачу правильно.
s> Один вопрос: человек до этого кодил на C или C++? А то у меня Deja vu.
Мне это неизвестно. Обычно он пишет на Дельфях приложения несколько критичные ко времени выполнения.
Здравствуйте, xobotik, Вы писали:
x> AN>Вы наверное еще не были в разделе "открытые проекты" и RSDN@Home?
x> Неа =) надо покурить этот хоум=)
Осторожно — можно подсесть капитально
x> А по поводу задачки, ну вот вроде решил:
Ну задачки для решения вроде не ставилось, но за прилежание x>
x> public void WriteTransformation(ref byte[] buffer, ref int dataLength, WriteByteHandler handler)
x> {
x> if (buffer == null) return;
x> if (dataLength < 0) return;
x> if (handler == null) return;
x> if (dataLength < buffer.Length)
x> {
x> for (int i = dataLength; i > 0; i--)
x> {
x> buffer[i] = buffer[i - 1];
x> }
x> buffer[0] = PREFIX;
x> }
x> if (dataLength >= buffer.Length)
x> {
x> byte[] newArray = new byte[dataLength + 1];
x> for (int i = 0; i < buffer.Length; i++)
x> {
x> newArray[i + 1] = buffer[i];
x> }
x> newArray[0] = PREFIX;
x> buffer = newArray;
x> }
x> dataLength++;
x> }
x>
x> P.S. Конечно можно было выделить как минимум один дополнительный метод это сдвиг элементов массива в право на N позиций, x> но стоит задача в рамках одного метода реализовать, как я понял. x> Так же конечно можно было воспользоваться встроенным методом Array.Copy вместо участка кода:
Что мне лично тут не нравиться
— вместо
if (dataLength < buffer.Length)
{
...
}
if (dataLength >= buffer.Length)
лучше было бы.
if (dataLength < buffer.Length)
{
...
}
else
А то начинаешь мучительно думать,каким образом получается dataLength > buffer.Length и кстати, в этом случае, код будет неправильно работать.
— Для одного и того же действия используются различные имплементации.
— Старый алгоритм работы метода не был скопировал, а именно, что при "нулевом" буфере возвращается префикс. x>
x> for (int i = 0; i < buffer.Length; i++)
x> {
x> newArray[i + 1] = buffer[i];
x> }
x>
x> но как-то нарушается эстетика всего метода, а конкретнее симметрия, чисто мое мнение =) x> Да и еще не рассмотрел случай, когда передается пустой buffer, но dataLength отлична и больше нуля, надо ли рассматривать такой случай?
Ценное замечания, старая функция на этом пролетает.
Надо рассматривать все что "выбьет" метод, может быть и спорно, на зато QA не будут получать повода для радости и уколок.
Здравствуйте, AlexNek, Вы писали:
AN>Что то часто мне стал попадаться код в который сразу не врубишься, при этом код делает свою задачу правильно. Предлагаю постить сюда ваши образчики и комментарии.
public void WriteTransformation(ref byte[] buffer, ref int dataLength, WriteByteHandler writeByteHandler)
{
if (writeByteHandler == null)
return;
if (dataLength < 0)
throw new ArgumentOutOfRangeException("Data length should be non-negative", dataLength, "dataLength");
if (buffer == null)
buffer = new byte[0];
if (dataLength > buffer.Length)
throw new ArgumentOutOfRangeException("Data length should not exceed the buffer length", dataLength, "dataLength");
var newBuffer = new byte[dataLength+1];
newBuffer[0] = PREFIX;
Array.Copy(buffer, 0, newBuffer, 1, dataLength);
buffer = newBuffer;
dataLength++;
}
AN>Интересно сколько времени вам понадобилось, что бы понять как функция точно работает?
Довольно много.
Из глупостей:
1. Попытки на ходу исправить bufferLength. Зачем? Отрицательные размеры, а также размеры более длины переданного буфера не имеют физического смысла. Вместо того, чтобы пытаться их как-то скорректировать, нужно выбрасывать исключение — пусть вызывающая сторона исправляет свой код.
2. Попытки схитрить с переиспользованием существующего буфера. Зачем? Это что, оптимизация? Для оптимизации нужны результаты профайлера. Судя по остальному коду, профайлер этого никогда не мерил. Ну так и незачем заниматься усложнением на ровном месте. Выделяйте буфер всегда. Дорогая операция здесь — копирование, которое происходит в любом случае. Выделение пары сотен байт из кучи в управляемой среде ничего не стоит.
3. Повторение избыточных проверок. Это только запутывает код и мешает компилятору со средой проводить оптимизации. Проверили буфер на null один раз, в самом начале — и достаточно. Делать это в цикле тем более не имеет смысла.
4. Зачем растить столько ветвей в графе управления? DRY: достаточно ровно одной строки, которая приписывает префикс.
5. Отказ от использования встроенных средств. Array.Copy — то, что доктор прописал. Это мало того, что более понятно, так ещё и более оптимально (там внутри используется развёртка циклов и копирование как минимум по DWORD за раз). За побайтное копирование в 21 веке нужно бить логарифмической линейкой по пальцам.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, SergeyT., Вы писали:
ST>Здравствуйте, AlexNek, Вы писали:
AN>>Что то часто мне стал попадаться код в который сразу не врубишься, при этом код делает свою задачу правильно. Предлагаю постить сюда ваши образчики и комментарии. ST>[skiped]
AN>>Интересно сколько времени вам понадобилось, что бы понять как функция точно работает?
ST>Более того, я осмелился этот код переписать. Вот что у меня вышло:
Если я правильно понял, то передача buffer == null и bufferLength = 0 — корректна. В этом случае нужно вернуть буфер единичного размера с префиксом.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Если я правильно понял, то передача buffer == null и bufferLength = 0 — корректна. В этом случае нужно вернуть буфер единичного размера с префиксом.
Но это нифига непонятно и неожиданно. Лучше явно декларировать свои намерения — отдельным методом.
Здравствуйте, Sinix, Вы писали:
S>>Если я правильно понял, то передача buffer == null и bufferLength = 0 — корректна. В этом случае нужно вернуть буфер единичного размера с префиксом. S>Но это нифига непонятно и неожиданно. Лучше явно декларировать свои намерения — отдельным методом.
Не вижу ничего неожиданного в том, что метод трактует new byte[0] и null одинаково.
А вообще — задачи чинить архитектурные проблемы не ставилось. Может, там вообще всё надо нахрен переделать, сократив объём кода раз в пять
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S> AN>Что то часто мне стал попадаться код в который сразу не врубишься, при этом код делает свою задачу правильно. Предлагаю постить сюда ваши образчики и комментарии.
S> AN>Интересно сколько времени вам понадобилось, что бы понять как функция точно работает?
S> Довольно много.
Как говорится, что и требовалось доказать S> Из глупостей:
Они и должны были быть в подобном коде (под данной рубрикой) и хорошо что Вы их перечислили. S> 1. Попытки на ходу исправить bufferLength. Зачем? Отрицательные размеры, а также размеры более длины переданного буфера не имеют физического смысла. Вместо того, чтобы пытаться их как-то скорректировать, нужно выбрасывать исключение — пусть вызывающая сторона исправляет свой код.
В данном случае важнее была работоспособность. S> 2. Попытки схитрить с переиспользованием существующего буфера. Зачем? Это что, оптимизация? Для оптимизации нужны результаты профайлера. Судя по остальному коду, профайлер этого никогда не мерил. Ну так и незачем заниматься усложнением на ровном месте. Выделяйте буфер всегда. Дорогая операция здесь — копирование, которое происходит в любом случае. Выделение пары сотен байт из кучи в управляемой среде ничего не стоит.
Специальных исследований не проводил, но помнятся противоположные результаты.
S> 3. Повторение избыточных проверок. Это только запутывает код и мешает компилятору со средой проводить оптимизации. Проверили буфер на null один раз, в самом начале — и достаточно. Делать это в цикле тем более не имеет смысла.
if (newBuffer != null) if (buffer != null)
Уже только эту строку можно занести в шедевры "как не надо" S> 4. Зачем растить столько ветвей в графе управления? DRY: достаточно ровно одной строки, которая приписывает префикс.
С последним предложеним как то не совсем понятно S> 5. Отказ от использования встроенных средств. Array.Copy — то, что доктор прописал. Это мало того, что более понятно, так ещё и более оптимально (там внутри используется развёртка циклов и копирование как минимум по DWORD за раз). За побайтное копирование в 21 веке нужно бить логарифмической линейкой по пальцам.
Если предоставите линейку напрокат
Здравствуйте, AlexNek, Вы писали: AN>В данном случае важнее была работоспособность.
Я не понимаю, о какой работоспособности можно говорить в коде, где кто-то присылает массив длинной 10 и просит отправить 15 байт.
Значит, автор кода забыл добавить последние 5 байт, и в устройство в результате вашей "починки" уезжает мусор. Именно такие попытки "починить на ходу" отвечают за сверхъестественно выглядящие баги, которые ищутся годами. Поверьте мне — я в детстве тоже так делал. AN>Специальных исследований не проводил, но помнятся противоположные результаты.
Результаты вам помнятся по С++.
S>> 3. Повторение избыточных проверок. Это только запутывает код и мешает компилятору со средой проводить оптимизации. Проверили буфер на null один раз, в самом начале — и достаточно. Делать это в цикле тем более не имеет смысла. AN>
if (newBuffer != null) if (buffer != null)
AN>Уже только эту строку можно занести в шедевры "как не надо"
Сама по себе строка ничего особенно плохого не содержит. Важен контекст.
S>> 4. Зачем растить столько ветвей в графе управления? DRY: достаточно ровно одной строки, которая приписывает префикс. AN>С последним предложеним как то не совсем понятно
Посмотрите, сколько раз в исходном коде встречается строчка ...[0] = PREFIX.
Из-за того, что мест больше одного, нет никакой гарантии, что все ветви графа управления проходят через эту строчку. Объединяя ветви в одну и оставляя ровно одно присваивание, мы убеждаемся, что не бывает комбинации условий, когда в качестве префикса остаётся ноль.
S>> 5. Отказ от использования встроенных средств. Array.Copy — то, что доктор прописал. Это мало того, что более понятно, так ещё и более оптимально (там внутри используется развёртка циклов и копирование как минимум по DWORD за раз). За побайтное копирование в 21 веке нужно бить логарифмической линейкой по пальцам. AN>Если предоставите линейку напрокат
Можете угрожать wireless-шнуром. Не знаю почему, но неопытные разработчики боятся его до судорог.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S> AN>В данном случае важнее была работоспособность.
S> Я не понимаю, о какой работоспособности можно говорить в коде, где кто-то присылает массив длинной 10 и просит отправить 15 байт. S> Значит, автор кода забыл добавить последние 5 байт, и в устройство в результате вашей "починки" уезжает мусор.
Вы не учли одной вещи. Что принимающая сторона на линии А всегда ожидает заголовок в ваши 5 байт. S> Именно такие попытки "починить на ходу" отвечают за сверхъестественно выглядящие баги, которые ищутся годами. Поверьте мне — я в детстве тоже так делал.
Добавка байт была не починкой, а заданием класса/функции. Приведенный код возник когда выяснилось, что посылка вначале заголовка, а потом основного сообщения приводит к ошибкам на некоторых конфигурациях. Исправлять пришлось тому кто это нашел
S> AN>Специальных исследований не проводил, но помнятся противоположные результаты.
S> Результаты вам помнятся по С++.
Может быть. Сейчас решил чисто на шару проверить и получилось даже смешно
(No new) Repeats 500000 buffer size 256 time 00:00:00.5496574
(With new) Repeats 500000 buffer size 256 time 00:00:00.4979645
*
* (No new) Repeats 500000 buffer size 512 time 00:00:01.0589830
(With new) Repeats 500000 buffer size 512 time 00:00:00.9412769
*
* (No new) Repeats 500000 buffer size 1024 time 00:00:02.1139021
(With new) Repeats 500000 buffer size 1024 time 00:00:01.8606506
*
* (No new) Repeats 100000 buffer size 4096 time 00:00:01.7431369
(With new) Repeats 100000 buffer size 4096 time 00:00:01.5042657
*
* (No new) Repeats 100000 buffer size 8192 time 00:00:03.3840202
(With new) Repeats 100000 buffer size 8192 time 00:00:02.9811746
Надо бы еще IL глянуть
public static void InitBuffer(byte[] buffer)
{
for (int i = 0; i < buffer.Length; i++)
{
buffer[i] = 0x55;
}
}
private static void TestNoNew(int BufferLength, int RepeatCount)
{
byte[] buffer;
Stopwatch timer = new Stopwatch();
timer.Start();
buffer = new byte[BufferLength];
for (int i = 0; i < RepeatCount; i++)
{
InitBuffer(buffer);
}
timer.Stop();
Console.WriteLine("(No new) Repeats {0} buffer size {1} time {2}", RepeatCount, BufferLength, timer.Elapsed);
}
private static void TestWithNew(int BufferLength, int RepeatCount)
{
byte[] buffer;
Stopwatch timer = new Stopwatch();
timer.Start();
for (int i = 0; i < RepeatCount; i++)
{
buffer = new byte[BufferLength];
InitBuffer(buffer);
}
timer.Stop();
Console.WriteLine("(With new) Repeats {0} buffer size {1} time {2}", RepeatCount, BufferLength, timer.Elapsed);
}
S> S>> 3. Повторение избыточных проверок. Это только запутывает код и мешает компилятору со средой проводить оптимизации. Проверили буфер на null один раз, в самом начале — и достаточно. Делать это в цикле тем более не имеет смысла.
S> AN>
if (newBuffer != null) if (buffer != null)
S> AN>Уже только эту строку можно занести в шедевры "как не надо"
S> Сама по себе строка ничего особенно плохого не содержит. Важен контекст.
С точки зрения форматирования мне страшно понравилось S> S>> 4. Зачем растить столько ветвей в графе управления? DRY: достаточно ровно одной строки, которая приписывает префикс.
S> AN>С последним предложеним как то не совсем понятно
S> Посмотрите, сколько раз в исходном коде встречается строчка ...[0] = PREFIX.
Должна быть ровно один раз S> Из-за того, что мест больше одного, нет никакой гарантии, что все ветви графа управления проходят через эту строчку. Объединяя ветви в одну и оставляя ровно одно присваивание, мы убеждаемся, что не бывает комбинации условий, когда в качестве префикса остаётся ноль.
S> S>> 5. Отказ от использования встроенных средств. Array.Copy — то, что доктор прописал. Это мало того, что более понятно, так ещё и более оптимально (там внутри используется развёртка циклов и копирование как минимум по DWORD за раз). За побайтное копирование в 21 веке нужно бить логарифмической линейкой по пальцам.
S> AN>Если предоставите линейку напрокат
S> Можете угрожать wireless-шнуром. Не знаю почему, но неопытные разработчики боятся его до судорог.
У нас сейчас другая страшилка: Будешь писать плохой код прийдет микрософт WER и заберет твою прогу.
Здравствуйте, AlexNek, Вы писали:
AN>Здравствуйте, Sinclair, Вы писали:
S>> AN>В данном случае важнее была работоспособность.
S>> Я не понимаю, о какой работоспособности можно говорить в коде, где кто-то присылает массив длинной 10 и просит отправить 15 байт. S>> Значит, автор кода забыл добавить последние 5 байт, и в устройство в результате вашей "починки" уезжает мусор. AN>Вы не учли одной вещи. Что принимающая сторона на линии А всегда ожидает заголовок в ваши 5 байт. AN>Добавка байт была не починкой, а заданием класса/функции. Приведенный код возник когда выяснилось, что посылка вначале заголовка, а потом основного сообщения приводит к ошибкам на некоторых конфигурациях. Исправлять пришлось тому кто это нашел
Я не понимаю, о чём вы говорите. Я говорю о том, что код, который отправляет буфер размером в 10 байт, устанавливая bufferLength = 15, заведомо некорректен. Понимаете? Вы в вашем коде вместо того, чтобы сразу упасть (гуглить по fail fast) отправляете 11 байт вместо 16ти. Это может некоторое время выглядеть работающим, но впоследствии приведёт к совершенно сверхъестественному поведению, которое вы будете чинить годами.
S>> Результаты вам помнятся по С++. AN>Может быть. Сейчас решил чисто на шару проверить и получилось даже смешно
Мерили в релизе или в дебаге?
S>> S>> 3. Повторение избыточных проверок. Это только запутывает код и мешает компилятору со средой проводить оптимизации. Проверили буфер на null один раз, в самом начале — и достаточно. Делать это в цикле тем более не имеет смысла.
S>> AN>
if (newBuffer != null) if (buffer != null)
S>> AN>Уже только эту строку можно занести в шедевры "как не надо"
S>> Сама по себе строка ничего особенно плохого не содержит. Важен контекст. AN>С точки зрения форматирования мне страшно понравилось
Ну, это уже мелкие красивости, типа i++ + ++i
S>> Посмотрите, сколько раз в исходном коде встречается строчка ...[0] = PREFIX. AN>Должна быть ровно один раз
Виноват, посмотрел не в ваш код. Да, у вас это таки правильно
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S> S>> AN>В данном случае важнее была работоспособность.
S> S>> Я не понимаю, о какой работоспособности можно говорить в коде, где кто-то присылает массив длинной 10 и просит отправить 15 байт. S> S>> Значит, автор кода забыл добавить последние 5 байт, и в устройство в результате вашей "починки" уезжает мусор.
S> AN>Вы не учли одной вещи. Что принимающая сторона на линии А всегда ожидает заголовок в ваши 5 байт. S> AN>Добавка байт была не починкой, а заданием класса/функции. Приведенный код возник когда выяснилось, что посылка вначале заголовка, а потом основного сообщения приводит к ошибкам на некоторых конфигурациях. Исправлять пришлось тому кто это нашел
S> Я не понимаю, о чём вы говорите. Я говорю о том, что код, который отправляет буфер размером в 10 байт, устанавливая bufferLength = 15, заведомо некорректен. S> Понимаете? Вы в вашем коде вместо того, чтобы сразу упасть (гуглить по fail fast) отправляете 11 байт вместо 16ти. Это может некоторое время выглядеть работающим, но впоследствии приведёт к совершенно сверхъестественному поведению, которое вы будете чинить годами.
Не понимаю также при чем здесь 15/16 байт?
У нас есть специальные куски кода которым просто запрещено выкидывать исключения.
Ну как пример, вы не можете в книге причитать строку. Вместо того чтобы сказать строка не читается, ложи книгу назад (fail fast) мы читаем книгу дальше и просто помечаем строку красным цветом. По моему это более приемлимо для пользователя.
S> S>> Результаты вам помнятся по С++.
S> AN>Может быть. Сейчас решил чисто на шару проверить и получилось даже смешно
S> Мерили в релизе или в дебаге?
Дебаг. Можно и релиз глянуть... получше
(No new) Repeats 100000 buffer size 8192 time 00:00:02.7632629
(With new) Repeats 100000 buffer size 8192 time 00:00:02.9427531
Здравствуйте, SergeyT., Вы писали:
ST>Более того, я осмелился этот код переписать. Вот что у меня вышло:
ST>
ST>public byte[] WriteTransformation(byte[] buffer, int bufferLength)
ST>{
........
ST>}
ST>
В мне кажется ваш код ничем не лучше изначального. Слишком уж сложно для такой довольно тривиальной (правда с несколькими вырожденными случаями) операции. Комментариев — примерно столько же, сколько и кода.
Рядом есть вариант от Sinclair, ИМХО в разы лучше.
Здравствуйте, AlexNek, Вы писали:
AN>У нас есть специальные куски кода которым просто запрещено выкидывать исключения.
Т.е. даже если все хреново, и задача не выполнена, притворись, что все хорошо?
А если исключение выбросит сторонний код, используемый вашим кодом?
Здравствуйте, HowardLovekraft, Вы писали:
HL>Здравствуйте, AlexNek, Вы писали:
AN>>У нас есть специальные куски кода которым просто запрещено выкидывать исключения. HL>Т.е. даже если все хреново, и задача не выполнена, притворись, что все хорошо? HL>А если исключение выбросит сторонний код, используемый вашим кодом?
HL>
Задача выполнена, но с ошибками. вроде пример с чтением книги приводил.
Возьмер допусти OCR прогу. Не может она распознать один символ и выкидывает при этом исключение — "Стор. Не могу распознать символ". Вам это понравится
Здравствуйте, AlexNek, Вы писали:
AN>Задача выполнена, но с ошибками. вроде пример с чтением книги приводил. AN>Возьмер допусти OCR прогу. Не может она распознать один символ и выкидывает при этом исключение — "Стор. Не могу распознать символ". Вам это понравится
По-вашему исключения придумали что бы морочить ими голову пользователям?
Здравствуйте, samius, Вы писали:
S>Здравствуйте, AlexNek, Вы писали:
AN>>Задача выполнена, но с ошибками. вроде пример с чтением книги приводил. AN>>Возьмер допусти OCR прогу. Не может она распознать один символ и выкидывает при этом исключение — "Стор. Не могу распознать символ". Вам это понравится
S>По-вашему исключения придумали что бы морочить ими голову пользователям?
Я только говорю, что не следует все мешать в одном корыте
Здравствуйте, AlexNek, Вы писали:
AN>Здравствуйте, samius, Вы писали:
S>>Здравствуйте, AlexNek, Вы писали:
AN>>>Задача выполнена, но с ошибками. вроде пример с чтением книги приводил. AN>>>Возьмер допусти OCR прогу. Не может она распознать один символ и выкидывает при этом исключение — "Стор. Не могу распознать символ". Вам это понравится
S>>По-вашему исключения придумали что бы морочить ими голову пользователям? AN>Я только говорю, что не следует все мешать в одном корыте
Вот и не мешайте все в одно корыто. На примере OCR почувствуйте разницу между тем когда подали данные с нераспознаваемым символом, и тем когда подали поток данных недостаточной длины.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, AlexNek, Вы писали:
AN>>Здравствуйте, samius, Вы писали:
S>>>Здравствуйте, AlexNek, Вы писали:
AN>>>>Задача выполнена, но с ошибками. вроде пример с чтением книги приводил. AN>>>>Возьмер допусти OCR прогу. Не может она распознать один символ и выкидывает при этом исключение — "Стор. Не могу распознать символ". Вам это понравится
S>>>По-вашему исключения придумали что бы морочить ими голову пользователям? AN>>Я только говорю, что не следует все мешать в одном корыте
S>Вот и не мешайте все в одно корыто. На примере OCR почувствуйте разницу между тем когда подали данные с нераспознаваемым символом, и тем когда подали поток данных недостаточной длины.
Так что надо вывалить исключение и сказать пшел вон?
По мне, так лучше показать пустую страницу и написать внутри что ее невозможно обработать.
Смысл в том что блок распознавания страниц должен всегда выдавать результат, а не передавать исключение наверх, те исключения просто обрабатываются "локально"
Здравствуйте, AlexNek, Вы писали:
AN>Здравствуйте, samius, Вы писали:
S>>Здравствуйте, AlexNek, Вы писали:
AN>>>Здравствуйте, samius, Вы писали:
S>>>>Здравствуйте, AlexNek, Вы писали:
AN>>>>>Задача выполнена, но с ошибками. вроде пример с чтением книги приводил. AN>>>>>Возьмер допусти OCR прогу. Не может она распознать один символ и выкидывает при этом исключение — "Стор. Не могу распознать символ". Вам это понравится
S>>>>По-вашему исключения придумали что бы морочить ими голову пользователям? AN>>>Я только говорю, что не следует все мешать в одном корыте
S>>Вот и не мешайте все в одно корыто. На примере OCR почувствуйте разницу между тем когда подали данные с нераспознаваемым символом, и тем когда подали поток данных недостаточной длины. AN>Так что надо вывалить исключение и сказать пшел вон?
Сначала надо уловить разницу между тем, что является корректным набором данных для метода и нет. В случае некорректного формата данных нужно кидать исключение сразу, так быстрее найдете то место, где они становятся некорректными. Вам Sinclair дал ссылку на FailFast.
AN>По мне, так лучше показать пустую страницу и написать внутри что ее невозможно обработать.
Исключение разве мешает это сделать?
AN>Смысл в том что блок распознавания страниц должен всегда выдавать результат, а не передавать исключение наверх, те исключения просто обрабатываются "локально"
Кто этот смысл выдумал?
Вообще не пойму, причем тут страницы, до сих пор речь шла о WriteTransformation
Здравствуйте, samius, Вы писали:
S>Здравствуйте, AlexNek, Вы писали:
AN>>Здравствуйте, samius, Вы писали:
S>>>Здравствуйте, AlexNek, Вы писали:
AN>>>>Здравствуйте, samius, Вы писали:
S>>>>>Здравствуйте, AlexNek, Вы писали:
AN>>>>>>Задача выполнена, но с ошибками. вроде пример с чтением книги приводил. AN>>>>>>Возьмер допусти OCR прогу. Не может она распознать один символ и выкидывает при этом исключение — "Стор. Не могу распознать символ". Вам это понравится
S>>>>>По-вашему исключения придумали что бы морочить ими голову пользователям? AN>>>>Я только говорю, что не следует все мешать в одном корыте
S>>>Вот и не мешайте все в одно корыто. На примере OCR почувствуйте разницу между тем когда подали данные с нераспознаваемым символом, и тем когда подали поток данных недостаточной длины. AN>>Так что надо вывалить исключение и сказать пшел вон? S>Сначала надо уловить разницу между тем, что является корректным набором данных для метода и нет. В случае некорректного формата данных нужно кидать исключение сразу, так быстрее найдете то место, где они становятся некорректными. Вам Sinclair дал ссылку на FailFast.
Я специально привел пример, когда этого не следует делать.
AN>>По мне, так лучше показать пустую страницу и написать внутри что ее невозможно обработать. S>Исключение разве мешает это сделать?
Да иногда может.
AN>>Смысл в том что блок распознавания страниц должен всегда выдавать результат, а не передавать исключение наверх, те исключения просто обрабатываются "локально" S>Кто этот смысл выдумал?
Наши принципы работы с пользователем
S>Вообще не пойму, причем тут страницы, до сих пор речь шла о WriteTransformation
Просто как более понятный пример