Шаблоны проектирования для управления результатами крупных операций

Question

У нас часто есть объекты, которые выполняют многоэлементные операции / задачи. Примером может быть обновление внутреннего состояния списка объектов на основе запроса файловой системы и чтение данных из найденных файлов. Эти вещи также часто выполняются долго и, как правило, выполняются в фоновых потоках (мы много работаем над Swing, но я думаю, что такого рода вещи будут применяться и к многоуровневым приложениям).

В операции такого рода вполне возможно, что часть операции потерпит неудачу (т.е. не сможет прочитать 5 или 6 из 5000 файлов, которые мы обрабатываем). В этом случае было бы неуместно выдавать исключение, но мы все же хотим предоставить пользователю обратную связь о том, что не произошло, и т. Д ...

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

Одной из мотивирующих концепций является валидация (у jgoodies хорошая реализация). Идея заключается в том, что при проверке значений в форме или структуре данных вы создаете объект ValidationResults, который может содержать объекты ValidationResult. Каждый ValidationResult имеет состояние (OK, WARN, ERROR), а также текст описания (и другие необходимые элементы).

Мне очень хочется просто использовать платформу проверки как есть для результатов задач.

Другой вариант - представить текущее состояние результата операции задачи как связанное свойство (возможно, используя список событий GlazedLists).

Мне было интересно, есть ли у кого-то еще какие-либо мнения / опыт в такого рода вещах, или какие шаблоны проектирования могли развиваться, чтобы справляться с долгосрочными задачами, которые могут иметь подзадачи, которые могут завершиться неудачей или не совсем завершиться идеально (т.е. состояние WARN)?

РЕДАКТИРОВАТЬ: разъяснение цели вопроса

Многие люди предлагают регистрировать проблемы и предлагать пользователю проверить с администратором. Чтобы немного прояснить проблему, рассмотрим приложение типа Eclipse. Если бы в процессе сборки были предупреждения или ошибки, а Eclipse просто выдавал диалоговое окно с сообщением об ошибке: «были проблемы, проверьте журналы», я думаю, что пользователь будет менее чем удовлетворен.

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

Два подхода, которые мы пробовали до сих пор, были:

1. Регистрация и добавление диалогового окна в конце процесса
2. Предоставление свойства, содержащего возникшие исключения

Мы пытаемся отойти от варианта 1 b / c взаимодействия с пользователем.

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

Исключения хороши для подпрограмм, которые имеют сбои в "остановке мира" (подпрограмма либо завершается успешно, либо каким-либо образом завершается с ошибкой), а создание исключений является очень хорошим сквозным механизмом для обработки таких ситуаций.

Но когда подпрограмма не попадает в простую категоризацию «пройдено / не выполнено», все становится немного неясным - сама подпрограмма может частично преуспеть.

Итак, лучше ли передать «ProblemListener», в который мы сообщаем о проблемах? Или лучше, чтобы программа возвращала список проблем? Или объект выставил свойство проблем из последнего запуска подпрограммы?

Есть много потенциальных решений - мне интересно, есть ли у кого-нибудь опыт их применения, и нашли ли они наилучшую практику (и по каким причинам они принимают или отвергают данный подход)?

Answer 1

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

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

Answer 2

Хотя вопрос старый, вот мои 5 центов:

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

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

Answer 3

Когда вы говорите «Объекты», я читаю Пакеты (по крайней мере, как одно из следствий), и я согласен, что ведение журнала является подходящим обычным способом для решения этой проблемы, но с Идентификатором Пакета, либо как поле в записи журнала, либо возможно, с большей вероятностью отдельный файл журнала для каждой партии, если процесс мониторинга, размер партии и число объектов делают это работоспособным.

Answer 4

Исключения обычно являются правильным способом сигнализации о том, что какая-то операция завершилась неудачно в Java. Я думаю, что какой бы ни был ваш подход, выбрасывать исключение на случай, если что-то не так - путь. В нашей компании мы используем эту 3-ю библиотеку для сохранения объектов в пакетном режиме, и в случае, если что-то пойдет не так, вся операция завершится неудачно, и исключение, которое они выдают, содержит подробные сведения о каждой ошибке и список объектов, которые не были импортированы. Затем мы попробуем еще раз со здоровыми объектами. Если вы не можете сделать это, потому что ваша операция не является транзакционной, я бы выбрал один из вариантов:

• Ошибка с исключением, содержащим список исключений и список неисправных объектов;
• Ошибка со списком объектов, каждый из которых содержит:
  • Уровень ошибки (ОШИБКА, ПРЕДУПРЕЖДЕНИЕ);
  • Сообщение об ошибке;
  • Неисправный объект.

Мне не нравится подход не генерировать исключение (например, возвращая значение ошибки), потому что он опирается на то, что разработчики проверяют возвращаемое значение в вашем методе, что не является стандартным способом обработки ошибок в Java. , Я также не стал бы подходить к ведению журнала, поскольку он заставлял бы пользователя копаться в файлах журнала, чтобы найти, что пошло не так.

Однажды я работал в этой компании, у которой были клиентские устройства, которые должны были выполнять задачи синхронизации. Каждое клиентское устройство имело запись в таблице «устройств», и эта таблица содержала информацию о последней синхронизации - если она прошла успешно, а если нет, то что пошло не так. Это хороший подход, если ваша задача выполняется службой, а не в результате вызова метода - или, лучше сказать, если ваша задача асинхронная. Кто-то просит запустить задачу, может получить или не получить событие о ее завершении, а затем проверяет ее результаты.

Answer 5

То, что вы пытаетесь сделать, - это, по сути, регистрация, и по этой причине я согласен с ответом, в котором говорится, что вы должны просто регистрировать результаты.

Я бы пошел еще дальше, чтобы сказать, что если вы используете log4j, вы можете создать собственный appender, который будет знать, как обрабатывать события журнала такого типа, и действовать соответствующим образом (если это WARN, ничего не делать, если он ОШИБКА оповещения пользователя и т. д.). Более того, если вы спроектируете вещи правильно, вы можете сохранить их в настройках через log4j.properties (или log4j.xml)

Answer 6

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

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

Что было бы неплохо, так это позволить пользователю затем решить проблему и добавить ее обратно в очередь для повторной обработки. :)