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

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

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

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

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

На уровне представления существует другая выгода попытки, которая отображает MessageBox.

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

Где код получает доступ к веб-сервису, затем я думал, что создам свой собственный "WebServiceException", который был бы создан на уровне доступа к данным каждый раз, когда HttpException, WebException или SoapException брошены.

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

Я думаю, что должен, вероятно, добавить выгоду попытки к Основному (), который ловит Исключение, пытается зарегистрировать его, отображается, "Приложение встретилось с ошибкой" сообщение и выходит из приложения. Так, мой вопрос, кто-либо видит какие-либо дыры в моем плане? Есть ли любые очевидные исключения, которые я должен ловить или делаю эти в значительной степени покрывают его (кроме доступа к файлу - я думаю, что существует только 1 место где мы чтение-запись к файлу конфигурации).

8
задан Colin 20 April 2010 в 05:54
поделиться

2 ответа

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

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

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

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

На уровне бизнеса и данных будет много попыток / finally (то есть операторов using), но почти никогда не будет подвоха.

2
ответ дан 6 December 2019 в 00:06
поделиться

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

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

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

2
ответ дан 6 December 2019 в 00:06
поделиться
Другие вопросы по тегам:

Похожие вопросы: