Uso de NotImplementedException

Creo que NotImplementedException es realmente una buena práctica.

De hecho, si olvida implementar un método y lo usa más adelante en su proyecto (y créame, sucede), puede pasar mucho tiempo depurando en busca de lo que salió mal paso a paso. Si tiene la excepción, el programa se detendrá directamente, lo que provocará la excepción (si detecta la excepción, la encontrará rápidamente observando qué excepción detectó).

Recomendaría utilizar el NotImplementedException combinado con los comentarios TODO, de esa manera usted combina la ayuda de GUI (con las tareas en VS) y la seguridad del programa.

Para la versión de lanzamiento, es aún más importante en mi opinión, ya que en la mayoría de los casos preferiría que su programa se bloquee en lugar de que un programa funcione correctamente pero produzca resultados erróneos.

Depende de su filosofía general acerca de los errores y el manejo de errores. Soy el tipo de "error duro" de un tipo: lanzaré una excepción a la menor insinuación de que algo podría estar mal; Lo afirmaré todo; Si hay un error, si se esperaba que algo estuviera allí, y no lo está, o si algo está ahí, y no debería, todo el universo debe detenerse. El sonido de exclamación de Windows debe sonar siniestramente a través de los altavoces.

Hay otras personas que preferirían no ser molestadas con errores. Entonces, ¿qué pasa si lo enviamos al cliente y falta todo el módulo de informes porque nos olvidamos de codificarlo y nadie en las pruebas se dio cuenta, porque la aplicación estaba demasiado silenciosa al respecto? ¡Mejor no hacer nada, que lanzar una excepción en la cara del cliente!

Yo diría que es una buena idea. Por lo general, veo esas excepciones generadas por el código de esqueleto que se genera automáticamente a partir de un formulario o diagrama o algo así. La excepción me recuerda que debo implementar el código y se asegura de que habrá errores si intento usar la funcionalidad que se configuró pero que nunca se implementó por completo. A veces lo apago o lo reemplazo por algo que es menos probable que detenga la ejecución (como imprimir una advertencia en la consola), pero creo que funciona para mí.

Si está construyendo una biblioteca que otros usarán, tener esta excepción es mejor que la alternativa, que sería un usuario de su biblioteca que llama a una función y se pregunta por qué no sucedió nada. Por supuesto, todavía es bastante malo tener esta excepción en una biblioteca enviada, pero es mejor que fallas silenciosas, IMO.

Creo que es una buena práctica. La alternativa es propagar un valor o estado no válido, que afectará tanto al código de prueba como al de producción.

Después de todo, siempre uso NotImplementedException , para eso es.

Esto se relaciona con el concepto de "falla rápida": si su código está lanzando una excepción, debería quedar atrapado antes de comenzar la producción. Si llega a producción, al menos el cliente sabe que el ensamblaje es incorrecto .

Si el código devuelve un valor sin sentido o, para los métodos void , no realiza ninguna acción, los consumidores de su código podrían pensar razonablemente que la llamada fue significativa cuando no lo fue. Luego, más tarde, cuando obtienen algún código correcto, su código podría romperse porque depende del comportamiento incorrecto anterior.

¿Qué tipo de proyecto es este? ¿Trabajo o casa? En casa, haz lo que quieras, lo que mejor te recuerde que debes terminar lo que sea en lo que estés trabajando.

En el trabajo, termina de escribirlo.

No puedo ver una situación en la que pueda ingresar un código que pueda / pueda romper otros desarrolladores, control de calidad o una compilación.

Yo hago ambas cosas, pero un \ todo en mi doxygene autodocing y luego lanzo la excepción. De esa manera, si las personas no pueden ser molestadas en RTFM, al menos podrán averiguar por qué se bloqueó su programa, en lugar de preguntarse por qué hay una función declarada que no está devolviendo un valor lógico.