Excepción vs validación

Question

Me acabo de encontrar con un solucionador de propiedades que detecta excepciones (todas las excepciones; sé que eso es malo, pero no es relevante aquí), y solo las registra. En primer lugar, creo que también debería pasar por ellos; ¿Por qué esperar un choque y un estudio de registro cuando puede saber que algo anda mal de inmediato?

Sin embargo, mi pregunta principal es, ¿valido contra valores de fecha inválidos, agrego un objeto RuleViolation a un objeto ValidationRules en mi documento, o lanzo una excepción InvalidDate, o simplemente dejo que CLR arroje la excepción para mí (fechas inválidas no son más que fechas inválidas, no se ha comprobado su rango, etc.)

Answer 1

Deben emitirse excepciones siempre que el método o miembro de la clase no pueda completar la tarea para la que está diseñado.

Por lo tanto, para un ajustador de propiedades, si el colocador no puede establecer la propiedad, entonces debe lanzar una excepción.

En cuanto a si debe atraparlo y volver a lanzarlo, la respuesta es sí, pero solo si necesita procesar la excepción inmediatamente en el colocador, antes de pasarla por la pila ...pero iniciar sesión no es una razón para hacer eso. En general, debe implementar el corte transversal de excepciones en un nivel superior, donde NO se va a volver a lanzar la excepción ... si se está ocupando de esas preocupaciones transversales que están más arriba en alguna parte, entonces no , definitivamente no atrape y vuelva a tirar la misma excepción.

Sin embargo, si está escribiendo una herramienta o una biblioteca de marcos, donde quiere que los clientes de su componente tengan un conjunto claramente definido de excepciones esperadas, y ha definido sus propias excepciones personalizadas que su componente aplicará al código del cliente y qué componentes del cliente esperarán ver, entonces es posible que desee capturar excepciones generadas por CLR y volver a crear sus propias excepciones personalizadas. Incluir siempre la excepción subyacente real en la propiedad "InnerException" de excepciones personalizadas antes de pasarla por la pila, por lo que que los datos en él están disponibles para cualquier sistema que termine consumiéndolo.

Answer 2

La captura y el nuevo lanzamiento son lo peor que se puede hacer. Es costoso TRY, si solo vas a volver a plantear cuál es el punto? Puede catch unhandled exceptions with the global.asax, por ejemplo, si necesita iniciar sesión.

En términos de validación, desde una perspectiva web y siempre uso validadores de expresiones regulares para las fechas, éstos cliente fuego y del lado del servidor, así que sé cuando estoy dentro de un bloque de

if(Page.IsValid) 

que mi txtDate.Text es una válida fecha, así que no me molesto en verificar porque es un desperdicio.

Answer 3

Depende de la tarea específica en cuestión. Si está escribiendo una clase de biblioteca que se usará como componente en otros programas y el contrato del método de la clase dice que solo debe aceptar fechas válidas, lanzar la Excepción está bien.

Si acepta la entrada del usuario y luego espera una excepción es una mala práctica. En este caso, debe validar la fecha usted mismo.

Las excepciones son para casos excepcionales y no deben formar parte de su lógica. Por lo general, significa que el programador rompió un contrato.

Answer 4

Realmente depende de la lógica de su aplicación. Las excepciones solo deberían arrojarse para circunstancias que son excepcional. Para algo así como la validación, depende de la tolerancia de los datos no válidos.

Cuando está construyendo una aplicación interactiva y el usuario puede ingresar cualquier cosa, probablemente esté bien que el documento entre en un estado no válido y debe exponer la información de validación a través de propiedades en la clase de documento.

Si está procesando documentos preparados previamente a partir de una base de datos o un archivo de registro, probablemente no sea correcto que el documento no sea válido y continúe funcionando después de que pueda dañar los datos en el sistema. Cuando eso suceda, deberías tirar.

Answer 5

Creo que depende de dónde provengan los valores de fecha. Si proviene de la entrada del usuario o de alguna otra fuente donde sea perfectamente posible ingresar fechas "inválidas", entonces la validación sería el camino a seguir. Por otro lado, si no hay una razón previsible por la cual los valores de los datos puedan ser inválidos, entonces arrojar una excepción es apropiado.