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

S>Сталкивались ли вы с подобными системами, как обычно решают эти проблемы (проблема неполноты данных, что ли)?

Я при работе с набором кривейших вебных автомагазинов и их вебсервисов, которые были написаны автослесарями, возвращал не одно значение, а таблицу, с указанием — кто ответил, а кто — нет, и за какое время ответил.

S>Тогда коды возврата? Вернее список код возврата + сообщение?

Не коды возврата, а некая структура, содержащая в себе и успешные результаты и ошибки.

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

S>Сталкивались ли вы с подобными системами, как обычно решают эти проблемы (проблема неполноты данных, что ли)?

Сталкивался в начале карьеры с подобными (весьма критическими на тот момент) ошибками. Никто не знал, как их обрабатывать, а надо было.

S>И связанный с этим вопрос. Какой механизм для передачи информации о накопившихся ошибках лучше использовать? Ведь исключение (Exception) не выйдет, оно обрывает процесс исполнения. Тогда коды возврата? Вернее список код возврата + сообщение?

Договорились использовать механизм ретрейвов на основе исключений: когда система пытается несколько раз получить данные со сбойного узла, и каждый раз генерируется исключение, процесс повторяется пока не удаётся вернуть достоверные данные в общую "копилку" или закончится счётчик попыток. Если счётчик обнулён, а данные так и не получены, то от узла возвращается немыслимое значение, например, "99999" — данные недостоверны, последующий алгоритм разбора данных отлавливает это ошибочное значение и не использует в расчётах. Также записывается в протокол, что данные с такого-то узла не получены.
Таким образом, ведётся два учёта ошибочности данных: на уровне алгоритма сбора информации и на уровне алгоритма расчёта данных — проблему недостоверности можно делегировать (или отложить решение) на более продвинутые (стратегически-мыслящие) уровни, так как нижние уровни сделали что смогли: попытались решить проблему, смогли-не смогли, зафиксировали ошибку и не дали ей распространиться выше.

Так мы отвязались также и от синхронного способа получения информации, когда сбор информации с какого-то одного временно недоступного узла тормозит всю цепочку и система встаёт. Для сбора информации с N узлов можно задействовать пул из M воркеров (легковесных потоков) и этим решить проблему синхронности, переводя её в асинхрон.

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

ZEN>...от узла возвращается немыслимое значение, например, "99999"

Говорят, что у истоков Y2K стоял невинный коментарий:
установим недостижимую дату — 9/9/99

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

S>Ну хорошо. А что если это 1 функция, которая возвращает значение total. Куда там запихнуть информацию об ошибке? Вместо decimal вернуть объект, содержащий список ошибок?

Можно и так. А еще лучше список результатов, каждый из которых обернут в некий Option (с стояниями Some(значение) и None() или Error, который вместо None будет какую-то дополнительную информацию содержать.

S>И потом как их отобразить?

Тебе вот хороший вариант предложили с табличным представлением.

А вообще, тут надо больше деталей знать. Что за данные? Зачем они клиенту? Какова их важность?

S>Может просто в лог-файл?

Зависит от предыдущих вопросов. Но пользователю, скорее всего, будет интересно, что результаты не точные.

Если пользователю достаточно прикидочных данных, то можно попытаться локально прикопать старые результаты и посчитать среднее значение. Так ошибка будет минимально.

S>Но ведь пользователь не смотрит лог-файл. Значит при обновлении, сначала отобразить окошко со списком ошибок (желательно всплывающее), потом отобразить сумму? Или же возле суммы поставить звездочку, при наведении на которую будет инфо об ошибках?

Окошко тупо закроют не глядя. Так что писать надо рядом и не звездочку, а огромным красным текстом (ОРАТЬ).

Вообще всегда исходи из того, что в среднем твой пользователь — олигофрен и читать и мысль не умеет. Так что делать так, чтобы даже олигофрену и полному кроту все было понятно. Если есть возможность понять не так, кто-то точно поймет не так, а окно пропустит.

S>По протоколу такого вообще не должно быть, нужно исправлять на сервере. Но почему то на сервере сделали с нарушением протокола.

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

S>Может просто отобразить ошибку, сумму не отображать и сказать чтоб исправили на сервере?

Это ты у пользователя должен спрашивать. Скажем если считаешь хэш файла, то смысла в неверном расчете — нет. Но если это какие-то там обороты по филиалам, филиалов тысячи, а 2-3 из них (причем мелких) не откликаются, то пользователю может быть интересна и не точная сумма.

Оптимальный вариант — предоставить пользователю выбор. По-умолчанию пишешь "нешмагга!" и предоставляешь переключатели "посмотреть без учета сбойных узлов", "посмотреть со срердними значениями для сбойных узлов". Ну, вариант с таблицей, опять же, хорош.

S>А до этого момента просто ошибка и все тут? Ведь во главе стоит протокол же...

Спроси у пользователей. Они что, недоступны?

Допустим, вам нужно посчитать сумму на всех счетах. И возникла ситуация, когда сумма на одном из счетов не установлена (т.е. API не возвращает значением суммы вообще), хотя согласно протоколу взаимодействия такая ситуация исключена. Выбор:

1. Либо отобразить сообщение об ошибке, сказать что на одном из счетов сумма не установлена. Но тогда даже примерной информации у пользователя не будет. Может ему будет полезна информация, что там как минимум 1 млн. руб. есть, пусть даже не удалось учесть все счета.
2. Просуммировать сумму на счетах, которые доступны, а там где нарушение протокола -- игнорить. Но тогда пользователь может быть введен в заблуждение, ведь некоторые счета просуммировать не удалось.
3. Выдать сообщение, что удалось просуммировать 100 счетов из 112, выдать что получилось и выдать какие счета не удалось учесть ввиду серверной ошибки.

Или другой пример.

Вам нужно посчитать количество товара, доступное во всех магазинах ваших конкурентов. У каждого магазина свое API, независимое. И при попытке получить кол-во товара, 3 магазина из 100 вернули ошибку. Что делать? Вообще не отображать информацию или же игнорить те, которые вернули ошибку и просуммировать имеющиеся данные?

Сталкивались ли вы с подобными системами, как обычно решают эти проблемы (проблема неполноты данных, что ли)?

И связанный с этим вопрос. Какой механизм для передачи информации о накопившихся ошибках лучше использовать? Ведь исключение (Exception) не выйдет, оно обрывает процесс исполнения. Тогда коды возврата? Вернее список код возврата + сообщение?

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

S>Допустим, вам нужно посчитать сумму на всех счетах. И возникла ситуация, когда сумма на одном из счетов не установлена (т.е. API не возвращает значением суммы вообще), хотя согласно протоколу взаимодействия такая ситуация исключена. Выбор:

S>1. Либо отобразить сообщение об ошибке, сказать что на одном из счетов сумма не установлена. Но тогда даже примерной информации у пользователя не будет. Может ему будет полезна информация, что там как минимум 1 млн. руб. есть, пусть даже не удалось учесть все счета.
S>2. Просуммировать сумму на счетах, которые доступны, а там где нарушение протокола -- игнорить. Но тогда пользователь может быть введен в заблуждение, ведь некоторые счета просуммировать не удалось.
S>3. Выдать сообщение, что удалось просуммировать 100 счетов из 112, выдать что получилось и выдать какие счета не удалось учесть ввиду серверной ошибки.

Ясен пестик — 3.

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

S>Сталкивались ли вы с подобными системами, как обычно решают эти проблемы (проблема неполноты данных, что ли)?

S>И связанный с этим вопрос. Какой механизм для передачи информации о накопившихся ошибках лучше использовать? Ведь исключение (Exception) не выйдет, оно обрывает процесс исполнения. Тогда коды возврата? Вернее список код возврата + сообщение?

Ким диктовал цифры, а Перец набирал их, нажимал на клавиши умножения и деления,
складывал, вычитал, извлекал корни, и все шло, как обычно.
–Двенадцать на десять, — сказал Ким. — Умножить.
–Один ноль ноль семь, механически продиктовал Перец, а потом спохватился и сказал:
–Слушай, он ведь врет. Должно быть сто двадцать.
–Знаю, знаю, — нетерпеливо сказал Ким.
–Один ноль ноль семь, –повторил он.
–А теперь извлеки мне корень из десять ноль семь...
–Сейчас, – сказал Перец

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

S>Допустим, вам нужно посчитать сумму на всех счетах. И возникла ситуация, когда сумма на одном из счетов не установлена (т.е. API не возвращает значением суммы вообще), хотя согласно протоколу взаимодействия такая ситуация исключена. Выбор:

Это должен знать заказчик. Если не знает, то предложи варианты, включая стоимость их написания, пусть выберет и утвердит.

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

S>Я же про API говорю. Вот есть API, для оценок допустимы значения только -1, 1, 2, 3. Для примера, может здесь и иначе.
S>Вы в клиенте суммируете все оценки и выводите итоговую сумму.

Ты меня не слушаешь. В Веб-реализации нет такого АПИ. Есть АПИ — передать оценку, получить текст для заполнения DIV-а.

В веб-сервисе для Януса возвращается список оцонок. Если там что-то не то вернется, ну будет вылет. Это баг в программе. Его править надо, а не замазывать.

Не тот случай.

S>И вдруг появляется новое значение -- смайлик. Протоколом не предусмотрено. Что делать? Пытаетесь преобразовать в число -- возникает ошибка. Значит пользователь либо:

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

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

S>Ведь можно изначально один подход выработать для случаев, когда не данные корректны.
Нельзя. Даже по твоим примерам это видно.
Сообщение форума вполне можно показать без оценок.
В том примере, который про количество товаров у конкурентов итоговую цифру имеет смысл сопроводить комментарием наподобие — "данные собраны по N источникам из M подлежащим мониторингу"
Там где сумма денег на разных счетах нужно явно сообщаать "Остаток по счету NNN в банке XXXXXXX получить не удалось", и лучше в общем виде причину ошибки, и в лог более специфическую информацию.

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

P>Сообщение форума вполне можно показать без оценок.
P>В том примере, который про количество товаров у конкурентов итоговую цифру имеет смысл сопроводить комментарием наподобие — "данные собраны по N источникам из M подлежащим мониторингу"

А разве сообщение на форуме не полезно снабдить подобным комментом?

P>Там где сумма денег на разных счетах нужно явно сообщаать "Остаток по счету NNN в банке XXXXXXX получить не удалось", и лучше в общем виде причину ошибки, и в лог более специфическую информацию.

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

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

S>Допустим, вам нужно посчитать сумму на всех счетах. И возникла ситуация, когда сумма на одном из счетов не установлена (т.е. API не возвращает значением суммы вообще), хотя согласно протоколу взаимодействия такая ситуация исключена.
Даже если бы протокол всегда выполнялся никто не может исключить ситуацию банального отсутствия связи с целевым сервером.

S>Выбор:
S>1. Либо отобразить сообщение об ошибке, сказать что на одном из счетов сумма не установлена. Но тогда даже примерной информации у пользователя не будет. Может ему будет полезна информация, что там как минимум 1 млн. руб. есть, пусть даже не удалось учесть все счета.
S>2. Просуммировать сумму на счетах, которые доступны, а там где нарушение протокола -- игнорить. Но тогда пользователь может быть введен в заблуждение, ведь некоторые счета просуммировать не удалось.
S>3. Выдать сообщение, что удалось просуммировать 100 счетов из 112, выдать что получилось и выдать какие счета не удалось учесть ввиду серверной ошибки.
Очевидно ответ зависит от того какой сценарий нужен пользователю.
Я полагаю в большинстве случаев это будет третий вариант.
Но в случае с подсчетом объема фалов в папке вполне может подойти и второй.
Первый вариант — неуважение к пользователю в любом случае и использоваться не должен.

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

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

S>Сталкивались ли вы с подобными системами, как обычно решают эти проблемы (проблема неполноты данных, что ли)?

Например, некоторые программы для визуализации размера папок пишут «3Gb+», где плюс означает, что результат предварительный, и часть ещё не посчиталась.

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

VD>Ясен пестик — 3.

Ну хорошо. А что если это 1 функция, которая возвращает значение total. Куда там запихнуть информацию об ошибке? Вместо decimal вернуть объект, содержащий список ошибок? И потом как их отобразить? Может просто в лог-файл? Но ведь пользователь не смотрит лог-файл. Значит при обновлении, сначала отобразить окошко со списком ошибок (желательно всплывающее), потом отобразить сумму? Или же возле суммы поставить звездочку, при наведении на которую будет инфо об ошибках?

По протоколу такого вообще не должно быть, нужно исправлять на сервере. Но почему то на сервере сделали с нарушением протокола.

Может просто отобразить ошибку, сумму не отображать и сказать чтоб исправили на сервере? А до этого момента просто ошибка и все тут? Ведь во главе стоит протокол же...

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

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

Во! Идея замечательная.

Но насколько гибкой должна быть система?

Вот, к примеру, возьмем этот форум и его API. API отдает оценки за сообщение, пусть по протоколу допустимо значение -1, 1, 2, 3 (для простоты). И вдруг там появляется значение "", которое протоколом не предусмотрено. Что делать? Не отображать вообще оценки для сообщения, где есть не предусмотренные протоколом значения? Или же игнорить то что не предусмотрено протоколом?

VD>По-умолчанию пишешь "нешмагга!"

А где это лучше писать? В окошке с ошибкой? Или лучше специальный лог ошибок сделать, чтбы он постоянно был перед глазами, а не там где-то под капотом? Встречались ли вам примеры где такое реализовано?

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

S> Вот, к примеру, возьмем этот форум и его API. API отдает оценки за сообщение, пусть по протоколу допустимо значение -1, 1, 2, 3 (для простоты). И вдруг там появляется значение "", которое протоколом не предусмотрено. Что делать? Не отображать вообще оценки для сообщения, где есть не предусмотренные протоколом значения? Или же игнорить то что не предусмотрено протоколом?

Если сервер отдаёт что=то не подходящее к протоколу — значит, или у тебя неправильная спецификация, или накосячили программисты сервера.
Насколько это критично — зависит от задачи.
В случае с оценкой на форуме — мир не погибнет, и эту ошибку можно игнорировать.
Если сервер выдаёт алярмы в системе СПРН — это вредительство в особо крупных, ст.58, пп 1,7,9,11, 14

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

С>Не коды возврата, а некая структура, содержащая в себе и успешные результаты и ошибки.
Которая вполне может заполняться информацией об ошибках в обработчике исключений, если так удобно.

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

B>

B>–Один ноль ноль семь, механически продиктовал Перец, а потом спохватился и сказал:
B>–Слушай, он ведь врет. Должно быть сто двадцать.
B>–Знаю, знаю, — нетерпеливо сказал Ким.

Во-во. Осмысленность этих систем в целом — отсутствует.

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

S>Вот, к примеру, возьмем этот форум и его API. API отдает оценки за сообщение, пусть по протоколу допустимо значение -1, 1, 2, 3 (для простоты). И вдруг там появляется значение "", которое протоколом не предусмотрено. Что делать? Не отображать вообще оценки для сообщения, где есть не предусмотренные протоколом значения? Или же игнорить то что не предусмотрено протоколом?

Этот форум отдает в качестве результата — текст (XTML). Причем делает это через AJAX (асинхронно). Клиентский скрипт тупо отображает, что прислали. Пришлют смайлик, отобразит его.

Это чистой воды баг и пытаться его как-то обработать — глупо. Его надо пойти и поправить.

Намного интереснее вопрос что делать при задержках в обмене. Вот у нас частенько бывает ситуация, когда жмешь yes в диалоге оценке, а оно тормозит и не закрывается. И хрен его знает не прошла ли посылка запрос на установку оценки или непрошел ответ.

Вот это поведение очень напрягает. По уму надо делать такой обмен асинхронно. Посылать оценку до тех пор пока не придет ответ. Ну, по крайней мере разумное число раз (и с разумной задержкой).

S>А где это лучше писать? В окошке с ошибкой?

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

S>Или лучше специальный лог ошибок сделать, чтбы он постоянно был перед глазами, а не там где-то под капотом? Встречались ли вам примеры где такое реализовано?

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

Свяжись с клиентами и спроси у них:
1. Насколько важны данные?
2. Что важнее точность (корректность) или актуальность?
3. Как отображать данные в случае отсутствия их с некоторых хостов?

Услышав ответы на вопросы, ты сам сможешь принять решение.

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

VD>Этот форум отдает в качестве результата — текст (XTML). Причем делает это через AJAX (асинхронно). Клиентский скрипт тупо отображает, что прислали. Пришлют смайлик, отобразит его.

Я же про API говорю. Вот есть API, для оценок допустимы значения только -1, 1, 2, 3. Для примера, может здесь и иначе.

Вы в клиенте суммируете все оценки и выводите итоговую сумму.

И вдруг появляется новое значение -- смайлик. Протоколом не предусмотрено. Что делать? Пытаетесь преобразовать в число -- возникает ошибка. Значит пользователь либо:

1. Вообще не увидит сообщения форумного.
2. Увидит сообщение, но не увидит оценку.
3. Увидит оценку на основе не полных данных, без учета смайлика.

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

VD>В веб-сервисе для Януса возвращается список оцонок. Если там что-то не то вернется, ну будет вылет. Это баг в программе. Его править надо, а не замазывать.

Как в идеале прога должна реагировать на баг?

К примеру, баг на сервере с оценками. Вариант:

1. Либо только отобразить ошибку, но не отображать сообщение и его ценки.
2. Либо отобразить только сообщение, а вместо оценок поставить красный восклицательный знак.
3. Либо отобразить и сообщение и те оценки, которые удовлетворяют протоколу.

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

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

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

Здравствуйте, VladFein, Вы писали:
VF>Здравствуйте, iZEN, Вы писали:
ZEN>>...от узла возвращается немыслимое значение, например, "99999"
VF>установим недостижимую дату — 9/9/99

Да уж, теперь все эти интмаксы вместо option и у меня глаз режут