Обработка кодов ошибок веб-службы (в дополнение к общим исключениям soapfaultex)

Question

В настоящее время я добавляю функциональность в приложение JSF / Richfaces, и теперь мы интегрируемся с внешними веб-службами.

Действия, выполняемые с услугами, включают: получение пользователя, получение учетной записи, обновление пользователя, обновление учетной записи, создание пользователя, создание учетной записи.

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

Вызовы выглядят следующим образом: BackingBean> Класс уровня менеджера (в основном, сквозной)> Клиент веб-службы (выполняет фактический вызов WS). Для действий GET идентификатор (имя пользователя или номер учетной записи) передается вниз, а объект Account или User - обратно. Обновления распространяются на объекты User / Account, как и Creates.

Каков наилучший способ вернуть эти ошибки обратно в бэк-бин, чтобы я мог обрабатывать их через пользовательский интерфейс?

1. Конечно, я мог бы проверять коды ошибок в ответе, генерировать исключение и продолжать отбрасывать его компоненту поддержки, где я бы обрабатывал его там.
2. Я мог бы реализовать тип Result, который будет содержать тип ошибки и POJO / DTO, которые я заполнял из службы.
3. Один из моих коллег порекомендовал использовать декоратор для украшения объектов USER или ACCOUNT с помощью валидаторов, которые мне также нужно было бы создать. По сути, я предполагаю, что мой декоратор будет просто содержать пользовательские типы ошибок, а Validate () просто проверит, если (List! = Null &&! (Size> 0)). Правильно?

Что вы думаете о предлагаемых методах? № 1 - самый простой, № 2 - более элегантный и простой, № 3 - самый «жесткий» для меня, поскольку я никогда не использовал шаблон декоратора. Тем не менее, № 3 кажется наиболее элегантным и в то же время самым трудоемким для реализации.

Дайте мне знать, если вам нужно больше разъяснений.

Спасибо, ТАК!

Answer 1

Всегда лучше программно ограничить использование исключений ( Когда генерировать исключение ).

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

Оба варианта 2/3 являются аналогичными решениями, поскольку вы просто пытаетесь вернуть дополнительную информациюк контроллеру.

Вариант 3 может считаться более чистым, но если у вас есть доступ к классам пользователей / учетных записей, вы всегда можете добавить в класс дополнительное свойство, которое может содержать ошибки проверки.1010 * Хорошим примером этого паттерна является ActiveRecord внутри ruby, модель того же типа.Вы вызываете save для объекта модели, если возникает ошибка, он заполняет свойство error.

Answer 2

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

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