Вопрос по web-services, soap – Должны ли веб-службы генерировать исключения ИЛИ объекты результатов

11

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

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

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

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

РЕДАКТИРОВАТЬ

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

@Джон: Да, это то, что я здесь говорю. К сожалению, это не вариант для меня. В противном случае это было бы гораздо более простой проблемой для меня :(. Ryan Tomlinson
На самом деле, я считаю, что способ удалить подробности исключений - поиграть с тегом customErrors в web.config. Хочешь верь, хочешь нет. John Saunders

Ваш Ответ

6   ответов
8

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

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

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

@Maladon: это хороший ответ, за исключением границ слоя. В общем, стратегии меняются на границах уровня, особенно на уровне обслуживания. В частности, для WCF граница слоя будет хорошим местом для обнаружения исключения "A". и замените его на FaultException & lt; AFaUlt & gt ;, который отправит ошибку SOAP AFault. Нет трассировки стека, кстати. ASMX не поддерживает неисправности должным образом; Еще одна причина, чтобы перестать использовать его.
6

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

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

Это не то, что я наблюдаю. Все мои веб-сервисы ASMX возвращают трассировки стека при настройках по умолчанию, и это сводит меня с ума. И когда есть цепочка сервисов, вызывающих друг друга, и последний в цепочке выбрасывает, клиент получает огромную трассировку стека от всех участвующих сервисов (в формеSoapException Message свойство которого содержит трассировку стека в виде связанного текста). Это ужасно, и я не знаю, как его выключить.
Ознакомьтесь с ошибками SOAP. Это стандартный способ возврата произвольной детали клиенту. В веб-службах ASMX их нужно возвращать «вручную». в свойстве Detail экземпляра SoapException, но это правильный путь, если вам нужно остаться с ASMX. Конечно, лучше всего использовать WCF. Кроме того, не думайте об этом как об информировании пользователей об исключениях. Исключения составляют детали реализации. Вы информируете их о неисправности.
@GSerg: вы бы отключили его одним из двух способов: 1. Переключитесь на WCF, где вы можете контролировать, есть ли детали в сообщении, и 2. Исправьте свой код, чтобы он не нарушался.
По сути, все, что я хочу сообщить пользователю, это исключение с кодом ошибки и описанием (по моему выбору). Я чувствую, что между обработкой исключений для веб-сервисов и для архитектуры приложений есть различие в семантике, но я не уверен относительно того, должны ли они рассматриваться по-разному. Вы бы не вернули объект Result в коде, когда есть ошибка. Должны ли веб-сервисы быть другими? Нет (как вы подразумеваете). Я предполагаю, что мой вопрос состоит в том, как мне абстрагировать детали исключения? Ryan Tomlinson
@JohnSaunders Я не переключаюсь на WCF по причинам совместимости, и код не нарушен, я охотно выкидываю исключение при обнаружении неверных параметров, предоставляя полезныеMessage, Я знаю, что могу вернуть фиктивный объект ответа сSuccess = false, но это глупо, как вы уже сказали в своем ответе, правильный способ - генерировать исключения. Я до сих пор не могу поверить, что невозможно отключить трассировку стека - в этом случае все клиенты всех публично предоставляемых сервисов ASMX могут просматривать свою структуру исходного кода так часто?
2

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

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

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

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

Как говорит @Джон, и я согласен, есть исключения, чтобы сообщить о неисправности. Исключения будут сериализованы в ошибку SOAP. В результате возвращение кода ошибки не очень хорошо вписывается в протокол. Увидеть ниже:msdn.microsoft.com/en-us/library/ds492xtk(VS.85).aspx Ryan Tomlinson
@James: придерживаться стандарта может быть лучше. Это обеспечивает ошибки, так почему бы не использовать их? Также разработчики забывают проверять коды ошибок. Вот почему были изобретены исключения, а ошибки SOAP являются версией исключений для веб-служб.
0

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

public void MyWebServiceMethod() {
try
{

 ///Do something that may cause an error

} catch(Exception ex)
{ throw new ApplicationException("User friendly descritption of exception");

}

}

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

catch(Exception ex) { throw ex; }

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

@ Богдан: Во-первых, MS устарела ApplicationException еще в .NET 1.1. Используйте & quot; Исключение & quot; вместо. Во-вторых, у меня сложилось впечатление, что ОП вообще не хочет трассировки стека.
@John, под ApplicationException я подразумевал любое пользовательское исключение. Хорошо, допустим, это должно быть MyWebServiceException или что-то вроде этого. Кроме того, на самом деле это не считается устаревшим, и исключения, такие как System.Threading.WaitHandleCannotBeOpenedException, все еще наследуют это. MS только говорит, что они не думают, что это очень ценно, но все же то, что вы используете в качестве базового класса для своих исключений, естественно, ваш собственный выбор, что также иногда диктуется соглашениями о кодировании, которым вы должны следовать в текущем проекте.
0

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

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

@John: см. Комментарий на оригинальный вопрос. К сожалению, не вариант для меня. Ryan Tomlinson
@ Брюс: неперехваченные исключения будут переведены в ошибки. При определенных обстоятельствах они будут включать, кроме деталей.
@Ryan: проработайте все комбинации тега customeError в web.config. Я считаю, что один из них отключает трассировку стека.
@ Брюс: Я понимаю, как работают веб-сервисы, я имею в виду больше архитектурного дизайна. Есть случаи, когда я требую исключения. В этих случаях информация трассировки стека сериализуется клиенту. Я не думаю, что это хорошая идея. Каков наилучший способ скрыть детали? Или является ответом, чтобы вернуть & quot; Возврат & quot; объект (пример, который я привел, был примером API CampaignMonitors). Ryan Tomlinson

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