Как рефакторинг использования общего исключения?

Question

Наш код везде ловит общее исключение.

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

Я ввел уровень бизнес-логики и уровень доступа к данным, чтобы раскрыть часть логики. На уровне доступа к данным я решил ничего не перехватывать, и я также выбрасываю ArgumentNullExceptions и ArgumentOutOfRangeExceptions, чтобы сообщение, переданное по стеку, не поступало прямо из базы данных.

В слое бизнес-логики я поставил попытку. В подвохе я откатываю транзакцию, делаю заготовка и переброска.

В слое презентации есть еще одна попытка перехвата, которая отображает MessageBox.

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

Когда код обращается к веб-службе, я думал, что создам свое собственное «WebServiceException», которое будет создаваться на уровне доступа к данным всякий раз, когда генерируется HttpException, WebException или SoapException.

Так что теперь, как правило, я буду ловить 2 или 3 исключения, в то время как в настоящее время я ловлю только общее исключение, и я думаю, что мне это кажется нормальным. Кто-нибудь еще раз переносит исключения, чтобы перенести сообщение на уровень представления?

Я думаю, что мне, вероятно, следует добавить функцию try catch в Main (), которая перехватывает Exception, пытается зарегистрировать его, отображает сообщение «Приложение обнаружило ошибку» и выходит из приложения. Итак, мой вопрос: кто-нибудь видит дыры в моем плане? Существуют ли какие-либо очевидные исключения, которые я должен отлавливать, или они в значительной степени покрывают это (кроме доступа к файлу - я думаю, что есть только 1 место, где мы можем читать и писать в файл конфигурации).

Answer 1

Я бы использовал try / finally (или оператор using, который эквивалентен) для вашего отката вместо того, чтобы делать это в блоке catch.В частности, если вы перехватываете только определенные исключения, вы все равно хотите, чтобы откат базы данных происходил при возникновении непредвиденного типа исключения.

За некоторыми исключениями я редко использую перехват в любом месте, кроме:

• На границе физического уровня я использую try / catch с log / throw в блоке catch, чтобы исключения могли регистрироваться на сервере.С более новыми технологиями, такими как WCF, исключения могут регистрироваться без попытки / улова (например, с WCF DispatchBehavior).

• В обработчике верхнего уровня на уровне представления.

На бизнес-уровне и уровне данных будет много попыток / окончаний (т. Е. С помощью операторов), но почти никогда не будет подвоха.

Answer 2

Похоже, вы делаете некоторые хорошие улучшения для вашего приложения. Я также обычно оборачиваю самый внешний слой приложения в блок try/catch Exception, чтобы неожиданные исключения (например, во время выполнения) могли позволить приложению корректно завершиться.

Один вопрос для вас, если имеет смысл делегировать бизнес-логике ответственность за откат данных . Это, казалось бы, лучше инкапсулировано в уровне доступа к данным. Затем вы могли бы выбросить исключение по вашему выбору из уровня данных вместо того, чтобы открывать этот уровень для выброса какого-либо старого исключения, потому что, что происходит с вашим уровнем бизнес-логики, если ваш уровень данных выдает то, чего вы не ожидали?

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