2011-03-21 27 views
5

Tengo un programa que llama a un servicio web externo, y quiero presentar al usuario un diálogo amigable si, por ejemplo, el servidor no funciona, alguien cortó el cable, etc. Suponiendo que el siguiente códigoLlamada al servicio web WCF: ¿qué excepción (s) atrapar?

try { 
    client.MyWebService() 
} 
catch(? ex) 
{ 
    // display friendly dialog explaining what went wrong 
} 

lo excepción (s) debería poner en lugar del signo de interrogación en el código? Es un poco difícil probar situaciones como esta cuando todo funciona sin problemas y no tengo control sobre la parte externa, por lo que se apreciará algo de información.

Gracias!

+0

Si quiere probar algunos escenarios específicos, entonces ... solo pruébelos y vea qué pasa? En parte, la respuesta depende de cuán importante es no filtrar ningún otro detalle además de los conocidos, es decir, ¿está bien mostrar "Oops, algo salió mal" + ex.Message –

+0

, aunque podría estar bien desde el punto de vista de la seguridad con un " Uy ... "mensaje, preferiría algo un poco más específico. – Eyvind

+3

"A la señora dos puertas abajo le están haciendo algunos quehaceres domésticos, y Jim, el más alto de los dos trabajadores actualmente en el sitio, accidentalmente puso una pala en la caja de conexiones, un ingeniero de telecomunicaciones fue llamado, pero tiene otros dos trabajos primero, además quiere comer esa albóndiga que tiene en su camioneta, esto se resolverá a las 14:12 "- no estoy seguro de que exista una excepción específica para eso ...; p –

Respuesta

5

Lo primero que debe hacer es aprovechar el evento .Faulted en su proxy, que se puede conectar de esta manera:

((ICommunicationObject)client).Faulted += new EventHandler(client_Faulted); 

En el controlador de eventos client_Faulted a continuación, puede intentar re conectando, o cambiando a un servidor de respaldo, o deshabilitando la UI, registrando el error, o mostrando un mensaje allí.

Obviamente, sigue siendo una buena práctica ajustar cada llamada en un try-catch también, pero el evento .Faulted puede permitirle lidiar con la mayoría de los problemas de canal incluso antes.

En cuanto a la excepción en sí, puede hacer que su servicio arroje un FaultException que se devuelve al cliente con los detalles que usted proporciona. Vea un ejemplo de su uso en this blog posting.

No obtendrá una FaultException si el canal en sí falla (FaultException es una forma de que el servidor comunique sus propios fallos internos al cliente).

Para las fallas del canal, puede obtener un CommunicationException o TimeoutException.

Finalmente, eche un vistazo a this project en Codeplex para generar los proxies WCF de manejo de excepciones. Puede darle una forma más flexible de entregar fallas.

1

No es realmente el trabajo del cliente proporcionar tantos detalles como sea posible. La cantidad máxima que realmente debe proporcionar en el lado del cliente es tanto como lo que obtiene en su excepción.

var userName = "bob"; 
try 
{  
    client.MyWebService(userName); 
} 
catch(Exception ex) 
{ 
    //Maybe we know WellKnownExceptions and can provide Foo advice: 
    if (ex is WellKnownException) 
    { 
     Console.WriteLine("WellKnownException encountered, do Foo to fix Bar."); 
    } 
    //otherwise, this is the best you can do: 
    Console.WriteLine(string.Format(
     "MyWebService call failed for {0}. Details: {1}", userName, ex)); 
} 
+3

Si sabe que podría arrojar una WellKnownException, entonces usted debería hacer que sea un bloque 'catch (WellKnownException wkex)' separado. –

+0

@CLaw: es una cuestión de estilo. Puede hacer una lógica más conciso si/then/else en este estilo, dependiendo del tipo de excepción que si cada uno tuviese su propio bloque catch. Sin embargo, mi ejemplo realmente no demuestra esto. –

Cuestiones relacionadas