Должны ли веб-службы генерировать исключения ИЛИ объекты результатов

Question

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

Я исследовал несколько реализаций, и, похоже, консенсуса по этому вопросу действительно не существует. Например, CampaignMonitor возвращает объект Result, а другие нет.

Архитектурно, я не уверен, что возвращать возвращаемый объект имеет смысл, конечно, исключение является исключением, но что мне нравится в возвращаемом объекте, так это то, что это более изящное решение для конечного пользователя.

У кого-нибудь есть лучшие решения?

EDIT

Кстати, я использую веб-сервисы ASMX, где включение CustomErrors не вариант.

Answer 1

Не позволяйте тому факту, что вы находитесь в веб-сервисе, запутать проблему. Это просто деталь реализации.

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

Таким образом, применительно к веб-сервисам - в общем случае генерировать исключения (что приводит к SoapFault). Это позволяет вызывающему клиентскому коду использовать встроенный стандарт обработки исключений для его обработки.

Answer 2

О какой трассировке стека вы говорите? Вы пробовали это?

В службах ASMX и WCF неперехваченное исключение будет преобразовано в сбой SOAP. В обоих случаях их можно настроить так, чтобы они не включали трассировку стека. На самом деле это значение по умолчанию в WCF.

Итак, правильный способ вернуть ошибку, подобную этой, - это ошибка. Один из способов генерировать ошибки - генерировать и не обрабатывать исключение.

Answer 3

Один из подходов - разделить системные и бизнес-ошибки. (Системная ошибка: например, неправильно сформированный запрос, пользователь не авторизован и т. Д .; бизнес-ошибка: например, метод UpdateCars приводит к ошибке, пользователь не владеет автомобилями).

В случае бизнес-ошибки вернуть объект ответа, содержащий описание ошибки; в случае системной ошибки выведите исключение.

Answer 4

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

Answer 5

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

public void MyWebServiceMethod () {
попробуйте
{

 ///Do something that may cause an error

} catch (Exex ex)
{ бросить новое ApplicationException ("Удобный для пользователя описание исключения ");

}

}

или вы также можете

catch (Exex ex) { бросить экс; }

Если вы повторно сгенерируете исключение, вы скроете исходную трассировку стека от клиентов ваших веб-сервисов.

Answer 6

Можете немного уточнить? На стороне сервера веб-службы может возникнуть исключение. На стороне сервера веб-службы может вернуть сообщение на стороне клиента. Это сообщение может содержать информацию об ошибке, и эта информация об ошибке может конкретно включать сведения об исключении. Или не может. На стороне клиента у вас обычно есть сгенерированный прокси-сервер для обработки сообщений с сервера. Этот прокси может генерировать исключение, если этот ответ содержит информацию об ошибке.

Какая часть этого сценария вас интересует?