Изключения за действие

Предишна 1 2 3 4 Страница 3 Следваща Страница 3 от 4

Примерен набор от изключения

На фигура 1 виждате четири вида изключения, предназначени да предприемат четири вида действия, както следва:

  1. BusinessException : Възникнало е изключително състояние. Това условие беше предвидено и може да бъде проверено чрез извикващия метод за незабавно действие.
  2. ParameterException : Въведените данни не позволяват правилна обработка. Потребителят трябва да бъде помолен да въведе отново валидни данни или да промени условията, при които се извършва обработката.
  3. TechnicalException : Възникна технически проблем като невалиден SQL израз. Заявената операция не може да бъде изпълнена. Потребителят трябва да се свърже с бюрото за разследване или да опита друга услуга. Използването на приложението от други потребители не е засегнато.
  4. CriticalTechnicalException : Възникна технически проблем като срив на база данни. При тези условия цялото приложение е неизползваемо. Потребителят трябва да бъде насърчаван да опита отново по-късно. Други потребители не трябва да използват приложението, докато то не бъде поправено.

Този набор от изключения е само един пример; много други набори от изключения могат да бъдат дефинирани по подобен начин. Например TechnicalExceptionи CriticalTechnicalExceptionможе да бъде проектиран като единичен клас на изключение с булев severityатрибут. Важното е да се съсредоточим върху вида на действието, което трябва да се предприеме, а не върху въпроса, повдигнал изключението.

Регистрация на изключения

Въпреки че семантиката на изключенията се фокусира върху действието, което е необходимо, повдигнатият въпрос също е важен. Екипът за разработка може например да използва тази информация за отстраняване на грешки в кода. В моя дизайн на изключение, информация за причината за изключението може да се намери в регистрационния файл за грешки на приложението. При наличието на добра рамка за регистриране трябва да е достатъчно да се регистрира информация за проблема от съобщението за изключение и проследяването на стека.

Единственият проблем, който остава в това как да се проектира изключението, така че тази информация да може лесно да бъде извлечена. Едно от решенията е да се предостави изключението с атрибут id , представляващ вида на проблема. Също така, ако проблемът е създал свое собствено изключение, това изключение може да бъде вложено в изключението на приложението. По време на улавяне оригиналното съобщение и проследяването на стека могат да бъдат извлечени от вложеното изключение. The ID атрибут и изключение гнездене са два начина да включват информация, свързана с проблем в самия изключение.

Проектиране на потока от изключения

След като сте проектирали самите изключения, следващата стъпка е да помислите как те ще преминат през вашето приложение. Стандартната архитектура за приложения на JEE се състои главно от четири пакета: презентация, бизнес, интеграция и постоянство. Изключения обикновено се създават от пакетите за интеграция и постоянство. В бизнес пакета вътрешните слоеве за изпълнение улавят проверените изключения възможно най-скоро, докато външните слоеве улавят изключенията по време на изпълнение и предприемат подходящи действия според класа си. Можете също така да хвърлите и уловите някои отметки с изключения в бизнес пакета. В тази схема отговорността на пакетите за интеграция и постоянство, както и на вътрешния слой на бизнес пакета, е да преобразува изключенията по време на изпълнение в действия.Типична архитектура за приложения на JEE от този вид е показана на фигура 2.

Пътят на изключение, хвърлено от пакета за постоянство (например), зависи от това къде може да бъде разрешен проблемът. Ако извикващият метод може да разреши проблема, изключението се улавя незабавно, предприемат се съответните действия и бизнесът протича нормално. Ако проблемът не може да бъде разрешен, изключението се влага в изключение по време на изпълнение и се предава безшумно през междинните слоеве на бизнес пакета към горните слоеве на приложението. В тези слоеве, обикновено от някакъв вид контролер на приложения, изключението по време на изпълнение се улавя, предприема се съответното действие и презентационният слой показва съответното съобщение за грешка на потребителя. Незабавното улавяне на проверените изключения и късното улавяне на изключения по време на изпълнение са двата основни сценария в този вид дизайн на изключения, както е показано на Фигура 3.