Где следует исключать исключения и обрабатывать их в приложении WPF?

Question

У нас есть код исключения в большинстве обработчиков событий и т. Д., Это приводит к очень сложной логике с флагами, которые заданы, если есть исключение, чтобы не сделать следующий шаг и т. Д.

Сначала Я бы переместил весь отчет об исключениях/запись в событие AppDomain.UnhandledException, однако из моего опыта работы с WinForms это приведет к тому, что многие исключения будут потеряны.

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

Так что люди опыт как плохо и хорошо при исключении регистрации/отчетности/восстановления в приложениях WCF?

(Я хотел бы сказать, что у нас есть что-то вроде шаблона ViewModel (MVVM) Model-View), но мы не имеем и далеки от возможности использовать любой «чистый» дизайн, подобный этому)

Answer 1

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

Исключения делятся на две категории:

• ожидается (например, проверка не удалась, данные не могут быть введены в базу данных)
• неожиданный

ваших ожидаемых должны быть обработаны довольно быстро, и регистрируется в зависимости от типа исключения. Например, если пользователь ввел некоторые данные, которые были отклонены кодом проверки на бизнес-уровне, я бы поймал исключение и уведомил пользователя, но не зарегистрировал его, потому что ожидалось, и я могу справиться с ним. Другие могут быть «ожидаемыми», но вы не можете справиться с этим - как вызов WCF не удалось из-за тайм-аута или большого пакета данных. Это вы должны обязательно регистрировать - вы даже сможете оправиться от него, поэтому еще раз его нужно поймать и решить. Обратите внимание на отсутствие флагов - исключение либо рассматривается, либо оно продолжает расти. Если вам нужно предпринять какое-либо действие, вы можете сделать это, а затем перестроить исключение, чтобы оно еще больше увеличилось - посмотреть, все еще нет флагов :)

Другой подход, который я использовал в прошлом при метании (обычае) ожидаемые исключения в приложении ASP.NET означают, что это можно обрабатывать локально или нет. Это означает, что когда aspx поймал ошибку (общий обработчик ошибок на базовой странице, наследуемый всеми apsx), тогда он знал, должен ли он просто показывать его локально внутри страницы (после выполнения текстового поиска в файле ресурсов) или должен ли он перенаправляться на страницу с ошибкой. Этот подход был особенно полезен, когда вы делаете смесь стандартных обратных передач и обратных вызовов ajax (возможно, это не особенно полезно для приложений WPF).

Для серьезных неожиданных ошибок вы можете поймать их на уровне приложения here is a previous SO post about it. Еще две связанные должности, которые могут быть полезны here и here.

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

Answer 2

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

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

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