Наш код ловит общее исключение везде.
Обычно это пишет ошибку в таблицу журнала в базе данных и показывает MessageBox пользователю, чтобы сказать, что операция, которую требуют, перестала работать. Если существует взаимодействие базы данных, транзакция откатывается.
Я представил слой бизнес-логики и уровень доступа к данным для распутывания части логики. На уровне доступа к данным я принял решение не поймать что-либо, и я также бросаю ArgumentNullExceptions и ArgumentOutOfRangeExceptions так, чтобы сообщение отказалось от стека, не прибывает прямо из базы данных.
В слое бизнес-логики я поместил выгоду попытки. В выгоде я откатываю транзакцию, делаю вход и перебросок.
На уровне представления существует другая выгода попытки, которая отображает MessageBox.
Я теперь думаю о ловле DataException и ArgumentException вместо Исключения, где я знаю, что код только получает доступ к базе данных.
Где код получает доступ к веб-сервису, затем я думал, что создам свой собственный "WebServiceException", который был бы создан на уровне доступа к данным каждый раз, когда HttpException, WebException или SoapException брошены.
Таким образом, теперь обычно я буду ловить 2 или 3 исключения, где в настоящее время я ловлю просто общее Исключение, и я думаю, что это кажется OK мне. Кто-либо оборачивает исключения снова для переноса сообщения до уровня представления?
Я думаю, что должен, вероятно, добавить выгоду попытки к Основному (), который ловит Исключение, пытается зарегистрировать его, отображается, "Приложение встретилось с ошибкой" сообщение и выходит из приложения. Так, мой вопрос, кто-либо видит какие-либо дыры в моем плане? Есть ли любые очевидные исключения, которые я должен ловить или делаю эти в значительной степени покрывают его (кроме доступа к файлу - я думаю, что существует только 1 место где мы чтение-запись к файлу конфигурации).
Я бы использовал try / finally (или эквивалентную инструкцию using) для отката, а не делал бы это в блоке catch.В частности, если вы перехватываете только определенные исключения, вам все равно нужно, чтобы откат базы данных происходил при возникновении неожиданного типа исключения.
За некоторыми исключениями я редко использую catch где-нибудь, кроме:
На границе физического уровня я использую try / catch с log / throw в блоке catch, чтобы исключения могли регистрироваться на сервере. С новыми технологиями, такими как исключения WCF, можно регистрировать без попытки / улова (например, с помощью WCF DispatchBehavior).
В обработчике верхнего уровня на уровне представления.
На уровне бизнеса и данных будет много попыток / finally (то есть операторов using), но почти никогда не будет подвоха.
Похоже на вас вносят несколько хороших улучшений в ваше приложение. Я также обычно заключаю самый внешний уровень приложения в блок try / catch Exception
, чтобы неожиданные исключения (например, во время выполнения) могли позволить приложению корректно завершиться.
Один вопрос к вам: есть ли смысл делегировать бизнес-логике ответственность за откат данных . Казалось бы, это лучше инкапсулировать на уровне доступа к данным. Затем вы могли бы выбросить исключение по вашему выбору из уровня данных, а не открывать этот уровень для генерации любого старого исключения, потому что что произойдет с вашим уровнем бизнес-логики, если ваш уровень данных выдает что-то, чего вы не ожидали?
Или что, если вы позже извлечете свой уровень доступа к данным и замените его чем-то другим? По крайней мере, вам придется удалить всю логику отката из уровня бизнес-логики.