Информирование конечного пользователя об исключениях в Winforms-MVP и WPF-MVVM

Question

В течение полугода Winforms-MVP я разработал следующую стратегию обработки исключений.У меня есть базовый абстрактный класс Presenter с несколькими методами Execute, принимающими делегат в качестве входного параметра (подписи меняются).Взаимодействие между представлением и представителем осуществляется через события (входные данные), определенные в IView, и путем установки открытых свойств (выходных данных) или вызова методов, определенных также в IView и реализованных представлением.Каждый обработчик событий в презентаторе вызывает один из методов Execute, предоставляя ему конкретную реализацию.

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

Не так давно (на самом деле ОЧЕНЬ не так давно) я начал изучать WPF-MVVM, который, на первый взгляд, имеет много общего с MVP.Я искал там несколько полезных советов относительно стратегии обработки исключений (в основном, информируя пользователя о проблемах), но в целом эти вопросы трудно найти - я имею в виду, что много сказано, но в основном в принципе.Я нашел более 20 примеров «обработки» необработанных исключений в app.xaml.cs, все это очень хорошо, но скажите мне искренне - если вы знаете точные исключения, которые могут привести к сбою приложения, не будете ли вы обрабатывать ихнемного раньше (даже если вы будете вынуждены закрыть свое приложение)?Я ни в коем случае не фанат ловить все возможные исключения.Довольно много исключений, которые вызваны проблемами с сетью, временной недоступностью базы данных и т. Д., Должны обрабатываться без закрытия приложения без значков страшных ошибок, дающих обычному пользователю возможность повторить свой запрос.

Так что в качестве эксперимента я попробовал почти то же самое, что описал ранее - я создал события в ViewModel для перехода к исключениям и подписался на них View.Но, честно говоря, этот способ вызывает у меня мурашки.

(это была очень длинная речь, я знаю) Вопрос: как вы обрабатываете исключения в том, что касается информирования пользователя при использованииMVVM?Нет, я не заинтересован в проверке данных только сейчас.Любая критика и / или советы по поводу MVP также приветствуются.

Answer 1

У нас есть несколько разных стратегий для разных типов ошибок в наших приложениях Wpf.

Для ожидаемых ошибок, которые код может обработать и продолжить без уведомления пользователя, мы делаем обычные блоки Try Catch.

Для ошибок, которые ожидаются, но которые приводят к сбою с точки зрения пользователей, мы выставляем коллекцию Notification на наших ViewModels, привязанную к ItemsControl на нашем View, который шаблонируется аналогичнопанели уведомлений в Firefox / IE / Chrome.Каждое уведомление имеет свойство длительности показа (коллекция уведомлений самостоятельно отбрасывается с использованием таймера диспетчера) и кнопку закрытия в представлении, чтобы они могли появляться в течение определенного периода времени или могли быть явно закрыты пользователем.Приятной особенностью этой модели является то, что ее можно использовать для сообщений о завершении, предупреждений и исключений, а также некоторых условий, которые могут не проявляться как исключение, но которые по-прежнему являются ошибочными с точки зрения пользователей.Уведомления часто являются хорошей заменой окна сообщений, поскольку они не прерывают рабочий процесс пользователей.

Для ошибок, которые мы не ожидаем, мы используем Red Gate SmartAssembly для сбора полной информации, чтобыпользователи могут отправлять их в нашу службу поддержки для анализа.Мы считаем, что перехват и продолжение вашего приложения после исключений, которые вы не ожидали, является очень рискованной стратегией - стек из неожиданного исключения не разматывается, и ваше приложение останется в несовместимом состоянии после ошибки (что может привести кот странного пользовательского интерфейса до повреждения данных) и могут быть побочные эффекты, которые невозможно предсказать.Сбой приложения не очень удобен для пользователя, но гораздо хуже - испортить данные из-за непредвиденного состояния, вызванного ошибкой, которая была проигнорирована приложением.Наша стратегия состоит в том, чтобы собрать как можно больше подробностей о сбое, чтобы пользователь знал, что мы серьезно относимся к решению проблемы, и мы исправим / поймаем ее в будущем обновлении - вместо того, чтобы просто продолжать и идти к потенциально худшим проблемам.

Answer 2

Я согласен, оставлять обработку исключений в вашем app.xaml.cs нехорошо, потому что это в основном слишком поздно!

Для операций, где потенциальное исключение относительно велико (обработка файлов, сетевой IO), убедитесь, что вы активно ловите исключения.Я открываю это для представления одним из двух способов:

1. Для ошибок, которые указывают на некоторые длительные проблемы, например, проблемы с сетью, я выставляю poperty ErrorState
2. Длявременные проблемы, например, файл не найден, выставить событие.