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

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

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


exception .net wcf web-services exception-handling
person brien    schedule 02.09.2008    source источник

Ответы (5)


arrow_upward
3
arrow_downward

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!"));
    }
}
person FlySwat    schedule 02.09.2008

arrow_upward
2
arrow_downward

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

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

person hova    schedule 02.09.2008

arrow_upward
1
arrow_downward

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

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

person Phil Bennett    schedule 02.09.2008

arrow_upward
0
arrow_downward

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

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

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

person brien    schedule 02.09.2008

arrow_upward
0
arrow_downward

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

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

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

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

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

person wojo    schedule 15.09.2008