2009-12-29 18 views
5

Cuando el servicio WCF está desactivado, voy a detectar esta excepción de esta manera.Qué hacer con una excepción detectada

public List<ProjektyEntity> GetProjekty() 
    { 
     try 
     { 
     return this.channel.GetProjekty(); 
     } 
     catch (EndpointNotFoundException exception) 
     { 
      //what to do at this point ? 
     } 
    } 

Pero no sé qué hacer en la captura bloque.conexión sólo puede devolver un objeto de tipo List<ProjektyEntity> me gustaría escribir un mensaje al usuario, algo así como "El servicio está desactivado "Mi capa de presentación es ASP.NET MVC. ¿Hay alguna estrategia para este tipo de situaciones?

Respuesta

15

Hay una regla simple: si no sabe cómo manejar una excepción, no la atrape.

Cogerlo y volver a ponerlo nulo o en una lista vacía sería lo peor que puede hacer, ya que será difícil depurar de dónde viene el error, o incluso si se produjo un error. Si haces esto, tendrás desarrolladores tirando de sus pelos.

Coger una excepción y volver a lanzarlo como throw e; también es malo porque pierde la pila original. Se acepta volver a tirar utilizando throw;, a veces, si tiene una limpieza especial, debe hacerlo solo si hay un error. Por lo general, este no es el caso. Si tiene que limpiar lo que debe hacerse ya sea que haya o no un error, pertenece a la cláusula finally.

Por lo tanto, en general, a menos que haya algo sensato que pueda hacer para recuperarse del error, simplemente permita que la excepción se propague a la persona que llama. Así es como las excepciones están diseñadas para funcionar.

Hay algunas veces en que es posible que desee capturar una excepción para añadir más información (por ejemplo, para la tala), en cuyo caso debe asegurarse de que se utiliza un InnerException para evitar perder la información original:

try 
{ 
    foo(bar); 
} 
catch (Exception e) 
{ 
    throw new FooException("Foo failed for " + bar.ToString(), e); 
} 

pero en general es mejor no hacer esto a menos que tenga una muy buena razón. Hacer esto evita que los usuarios capten un tipo específico de excepción: detectarán su excepción y luego deberán activar el tipo de InnerException. No es divertido. Solo deja que la persona que llama vea la excepción original.

+2

Parece que solo debe manejar esta excepción en la capa de presentación. Las excepciones deben ser excepcionales. Solo maneje excepciones si puede seguir una ruta lógica diferente en función de la excepción que se produce. –

4

Me parece que no debe detectar esta excepción en esa capa; debe permitir que la excepción se propague a la capa del controlador y permita que la capa del controlador muestre el mensaje.

8

Puedo ver algunas opciones aquí. Determinar cuál es el apropiado depende probablemente de la aplicación.

  • Muestra un error y devuelve nulo. Limpio y simple, pero inflexible. Puede no ser lo que desea en todos los casos donde se usa esta función.
  • No lo atrape, deje que la persona que llama capte esta excepción. Puede ser más fácil para determinar la respuesta adecuada de la función de llamada (es decir. Mostrar un mensaje/a intentarlo en unos segundos/etc)
  • cogerlo y lanzar una nueva ServiceNotAvailableException ligeramente más compleja que la segunda opción, pero lo hará hacer su código más claro.
  • Simplemente devuelva nulo. Probablemente el enfoque menos deseable a menos que este servicio sea inactivo es común y no es gran cosa.
1

Crear un objeto de excepción, con suficientes detalles de depuración y echarlo a la llamada al método

2

no se supone La excepción a ser capturados y manipulados en este contexto. Debe manejarse a un nivel mucho más alto teniendo acceso a cualquier consola en general.

Lo mejor que puede hacer aquí es simplemente registrar la excepción con los detalles necesarios y volver a crear correctamente.

4

Existen varios enfoques:

1) No detectar la excepción, y dejar que la persona que llama (capa de interfaz de usuario) manejarlo

2) detectar la excepción por lo que se puede hacer cualquier cosa que necesite hacer, y luego volver a tirar

catch (EndpointNotFoundException exception) 
{ 
    CleanUpMyOwnState(); 
    throw;     // Pass the exception on the to the caller to handle 
} 

3) Convertir la excepción en otro tipo (para que sea más fácil de manejar en la persona que llama):

catch (EndpointNotFoundException exception) 
{ 
    CleanUpMyOwnState(); 
    throw new InvalidOperationException("Endpoint was not found", exception); 
} 

4) atraparlo, y luego devolver un código de error (por ejemplo nulo), por lo que la persona que llama no necesita utilizar el control de excepciones para tratar con él (pero no hay ninguna ventaja real para hacer esto)

5) Capture la excepción e informe el error al usuario usted mismo. Esta es probablemente una mala idea: debe mantener todos los informes de errores en su capa de interfaz de usuario.

0
public List<ProjektyEntity> GetProjekty() 
    { 
     try 
     { 
     return this.channel.GetProjekty(); 
     } 
     catch (EndpointNotFoundException exception) 
     { 
      'Write here Some Clean Up Codes 
      ' Log it somewhere on your server so that you can fix the error 

     } 
    } 
Cuestiones relacionadas