Исключения в веб-сервисах - PullRequest
       28

Исключения в веб-сервисах

2 голосов
/ 02 сентября 2008

Моя группа разрабатывает приложение на основе сервисов (.NET WCF), и мы пытаемся решить, как обрабатывать исключения в наших внутренних сервисах. Должны ли мы бросать исключения? Возвращать исключения, сериализованные как XML? Просто вернуть код ошибки?

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

Ответы [ 5 ]

3 голосов
/ 02 сентября 2008

WCF использует SoapFaults в качестве собственного способа передачи исключений из службы клиенту или из клиента в службу.

Вы можете объявить пользовательскую ошибку SOAP, используя атрибут FaultContract в интерфейсе контракта:

Например:

[ServiceContract(Namespace="foobar")]
interface IContract
{
    [OperationContract]
    [FaultContract(typeof(CustomFault))]
    void DoSomething();
}


[DataContract(Namespace="Foobar")]
class CustomFault
{
    [DataMember]
    public string error;

    public CustomFault(string err)
    {
        error = err;
    }
}

class myService : IContract
{
    public void DoSomething()
    {
        throw new FaultException<CustomFault>( new CustomFault("Custom Exception!"));
    }
}
2 голосов
/ 02 сентября 2008

Ну, а почему бы просто не выбросить стандартные исключения SOAP? Проблема с кодами ошибок и сериализованным XML заключается в том, что им обоим требуется дополнительная логика, чтобы распознать, что ошибка действительно произошла. Такой подход полезен только в том случае, если у вас есть специализированная регистрация или логика, которая должна происходить на другой стороне веб-службы. Такой пример будет возвращать флаг, который говорит, что «это нормально, продолжить» с отчетом об исключительной ситуации.

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

1 голос
/ 02 сентября 2008

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

Обычно я бы сказал использовать контракты с ошибками WCF.

0 голосов
/ 15 сентября 2008

Я бы не стал отправлять исключения напрямую обратно клиенту, если вы не согласны с отправкой такой подробной информации.

Я бы порекомендовал использовать ошибки WCF для передачи вашего сообщения об ошибке и кода (что может быть использовано для принятия решения о том, что получатель должен повторить попытку, произошла ошибка и т. Д.), В зависимости от того, является ли отправитель или получатель ошибочным.

Это можно сделать с помощью FaultCode.CreateReceiverFaultCode и FaultCode.CreateSenderFaultCode.

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

.NET WCF сбои, генерирующие неправильные значения кода ошибки SOAP 1.1

0 голосов
/ 02 сентября 2008

Фил, разные части приложения вызывают друг друга с помощью WCF. Под «возвратом исключений, сериализованных в XML», я подразумевал, что возвращаемое значение функции будет объектом исключения. Успех будет обозначен нулем.

Не думаю, что это правильный вариант.

Контракты на ошибки WCF звучат хорошо, но я ничего о них не знаю. Проверка Google прямо сейчас.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...