2010-08-13 15 views
6

Al observar algún código reflejado desde las bibliotecas de WCF, estoy viendo un patrón utilizado para crear excepciones:¿Cuál es el valor de las fábricas de Excepción?

if(argument == null) 
{ 
    throw Error.ArgumentNull("argument"); 
} 

argumentos nulos siendo el ejemplo más simple, con otros tipos de excepciones disponibles a través de la clase de error estático.

¿Cuál es el valor de este patrón de fábrica? ¿Por qué no utilizar el operador new y simplemente llamar al constructor ArgumentNullException?

Respuesta

2

La razón más importante que he encontrado es para estandarizar cómo se manejan y definen las excepciones en el marco de un equipo de desarrollo (o equipos) en particular. Incluso Microsoft publica que los diversos tipos de excepciones no son específicamente estándar entre Exception, SystemException y ApplicationException. Podría ser que las necesidades de la excepción pueden ser diferentes dependiendo de las reglas que rigen los casos de lógica específica. También es útil para eliminar tareas comunes (como el registro) de las preocupaciones diarias del desarrollador. Todo lo que el desarrollador tiene que hacer es usar la excepción apropiada en la fábrica y la fábrica se encarga del resto.

+0

¿Tiene algún ejemplo del tipo de estandarización al que se refiere? –

+0

@Programming Hero: me refería a los estándares internos. Por ejemplo, dentro de nuestro equipo de desarrollo aquí en el trabajo, nosotros (los clientes potenciales) nos juntamos poco después de ser asignados a nuestro primer proyecto y explicamos lo básico de lo que queríamos: nombrar estándares, registro, manejo de excepciones, manejo de eventos, nivel n arquitectura, etc. No creamos una fábrica nosotros mismos, pero especificamos en nuestros documentos normativos que usen System.Exception en lugar de ApplicationException y los estándares para cuando las excepciones deben registrarse, capturarse, manejarse o ignorarse. –

0

¿La fábrica podría realizar trabajo adicional, como registrar la excepción quizás?

+1

Solo pudo registrar la creación de la excepción. Sin seguimiento de pila ni información realmente útil en esa etapa. –

+0

@ Héroe de programación: Podría _concebiblemente_ usar la clase 'StackTrace' para generar un seguimiento de la pila. No es que debería. –

5

Creo que la razón principal es que los mensajes de excepción .NET están localizados. El texto del mensaje real necesita ser recuperado de un recurso de cadena. Mejor poner ese tipo de código en un lugar para que nadie busque el nombre del recurso de cadena.

La idea de utilizar una fábrica para que el tipo de excepción real pueda ajustarse me parece poco útil. Hacerlo puede romper una gran cantidad de código de cliente que, por cualquier razón, intenta atrapar esa excepción. Una vez que envía el código que arroja una excepción específica, está bastante atrapado con él. Elija sabiamente :)

Cuestiones relacionadas