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

Question

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

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

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

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

Редактировать

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

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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

общедоступный недействительный MyWebServiceMethod() {
попробуй
{

 ///Do something that may cause an error

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

}

}

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

catch(исключение ex) { выбросить ex;}

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

Answer 6

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