¿Es una mala práctica escribir un método que no haga nada excepto lanzar una excepción?

Question

El título casi lo dice, pero aquí hay algunos antecedentes:

Tengo una aplicación ASP.Net MVC donde necesito comprobar una lista de rutas de archivos para la existencia. Si alguna de las rutas no existe, se devuelve un error.

Actualmente, tengo un controlador base donde se implementa el evento OnException. Aquí, se tratan las excepciones no manuales y se devuelve una página de error al usuario con el mensaje de la excepción.

La manera más simple para mí de hacer la comprobación anterior es escribir un método que compruebe la existencia de cada ruta y si alguno de ellos falla, simplemente tiro (y registro) una excepción. Esta excepción es manejada por el controlador base y se devuelve el mensaje apropiado al usuario.

Mi problema es que hacer esto parece una mala práctica. Estoy escribiendo un método que devuelve vacío y su único propósito es lanzar una excepción en el raro caso de que una de las rutas no exista, en la mayoría de los casos no hace nada. ¿Es una mala idea?

Answer 1

No hay nada de malo en eso.

El .NET framework también lo hace: por ejemplo, CancellationToken tiene un método ThrowIfCancellationRequested que no hace más que tirar o no tirar dependiendo de alguna condición.

Otro ejemplo: Dispatcher 'VerifyAccess método, que comprueba si la persona que llama está en el mismo hilo que se supone que se debe acceder al control, y tira si no.

Answer 2

En .net existe la opción de hacer un lanzamiento nuevo notimplementedexception, por lo que puede crear los métodos e implementarlos más adelante. Entonces, no es una mala práctica, la mala práctica es dejarlos allí cuando se libera la aplicación a la producción. Dar errores sin ninguna razón es una mala práctica.

Para TDD (desarrollo dirigido por prueba) puede ser muy útil también, usted crea el método, y luego la prueba de unidad que falla con la excepción no implementada y finalmente implementa el método para pasar la prueba.

Btw que estaba respondiendo el título de su pregunta, pero debe cambiar el nombre de la pregunta porque su método hace algo. Si hace algo y siempre arroja una excepción es una mala práctica, las excepciones son costosas, debe registrar el error y seguir adelante, sin excepción. Debería hacer una función PathExists que devuelva un booleano, esa es una mejor solución. (incluso si alguien me vota -1 sin ninguna razón ... Heheh)

Answer 3

Algunos pueden decir que es una mala idea pero, a veces, no hay una alternativa sensata. Si desea generar una excepción para comunicar un error a alguna persona que llama (tal vez aislada del creador mediante un código opaco de terceros), hágalo. El árbitro final - '¿funciona?'