Pregunta

Mi grupo está desarrollando una aplicación basada en servicios (.NET WCF) y estamos intentando decidir cómo manejar las excepciones en nuestros servicios internos.¿Deberíamos lanzar excepciones?¿Devolver excepciones serializadas como XML?¿Simplemente devolver un código de error?

Tenga en cuenta que el usuario nunca verá estas excepciones, solo son para otras partes de la aplicación.

¿Fue útil?

Solución

Usos de WCF SoapFaults como su forma nativa de transmitir excepciones del servicio al cliente o del cliente al servicio.

Puede declarar un error SOAP personalizado utilizando el FaultContract atributo en la interfaz de su contrato:

Por ejemplo:

[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!"));
    }
}

Otros consejos

Bueno, ¿por qué no simplemente lanzar las SOAPExceptions estándar?El problema con los códigos de error y el XML serializado es que ambos requieren lógica adicional para reconocer que realmente ocurrió un error.Este enfoque solo es útil si tiene un registro o una lógica especializados que deben realizarse en el otro lado del servicio web.Un ejemplo de este tipo sería devolver un indicador que diga "está bien continuar" con un informe de excepción de error.

Independientemente de cómo lo lance, no facilitará el trabajo, ya que la parte que llama aún debe reconocer que hubo una excepción y solucionarla.

Estoy un poco confundido, no estoy siendo frívolo: dices que quieres devolver excepciones serializadas como XML por un lado y que el usuario nunca verá las excepciones por el otro.¿Quién verá estas excepciones?

Normalmente diría que se utilicen contratos de error WCF.

Phil, diferentes partes de la aplicación se llaman entre sí mediante WCF.Por "devolver excepciones serializadas como XML", quise decir que el valor de retorno de la función sería un objeto de excepción.El éxito estaría indicado por nulo.

No creo que esa sea la opción correcta.

Los contratos de fallas de WCF suenan bien, pero no sé nada sobre ellos.Revisando google ahora mismo.

Evitaría enviar excepciones directamente al cliente a menos que esté de acuerdo con que se envíen tantos detalles.

Recomendaría usar fallas de WCF para transmitir su mensaje y código de error (algo que se puede usar para tomar una decisión sobre si el receptor debe volver a intentarlo, eliminar el error, etc.) dependiendo de si es el remitente o el receptor el culpable.

Esto se puede hacer usando FaultCode.CreateReceiverFaultCode y FaultCode.CreateSenderFaultCode.

Estoy en el proceso de revisar esto en este momento, pero parece que me encontré con un problema desagradable en la respuesta SOAP 1.1 generada por la falla de WCF.Si está interesado, puede consultar mi pregunta al respecto aquí:

Errores de .NET WCF que generan valores de código de error SOAP 1.1 incorrectos

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top