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

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

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

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

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

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