Шаблоны обработки ошибок для многопоточных приложений, использующих WF? - PullRequest
3 голосов
/ 10 февраля 2010

Я писал длинный подробный вопрос, но просто отказался от него в пользу более простого вопроса, на который я не нашел ответа.

Краткое описание приложения:

У меня есть приложение WPF, которое порождает несколько потоков, и каждый поток выполняет свой собственный WF. Каковы некоторые из лучших способов обработки ошибок в потоках и WF, которые позволят взаимодействовать с пользователем со стороны GUI? Я определенно планирую обработать любые исключения низкого уровня в потоке, потому что я не хочу, чтобы поток выходил.

Краткое изложение вопросов:

  1. Как вы реализовали связь между WF и потоком, который его запускает? Существует WorkflowTermination, но я не хочу, чтобы рабочий процесс завершился - мне нужно исправить проблему и дать ей продолжить. Я предполагаю, что единственным вариантом является использование FaultHandler, но мне было интересно, есть ли другой способ сделать это без использования блока активности. Я надеюсь, что есть рамки, которые я еще не нашел.

  2. Ошибка от WF должна быть поймана потоком, который затем должен отобразить ошибку в графическом интерфейсе. Затем пользователь сделает логический выбор для восстановления, которое затем следует отправить обратно в поток, а затем в WF. Опять же, существует ли что-то, на что я должен взглянуть?

Даже умные слова / ключевые слова, которые выполняют то, что я описываю, были бы действительно полезны, и я могу сделать работу по исследованию каждого из них. Тем не менее, любое дополнительное понимание всегда приветствуется. :)

Ответы [ 2 ]

1 голос
/ 10 февраля 2010

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

0 голосов
/ 10 марта 2010

Вот как я решил эту проблему. Но сначала небольшая справочная информация:

Пользователь нажимает кнопку в графическом интерфейсе, которая запускает упаковщик конфет. Это делается через привязку команды во ViewModel, которая затем вызывает низкоуровневую функцию в модели. Функция в модели запускает поток и выполняет конечный автомат.

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

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

Это работает очень хорошо (пока). Часть, которую я знаю, полностью хромает - это способ проверки предпочтительного метода восстановления после ошибок. По сути, я устанавливаю строковую переменную, а затем сравниваю эту строку со списком известных строк. Ультра хромая, но я не уверен в лучшем способе сделать это, кроме использования enum. У кого-нибудь есть рекомендации для меня?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...