Uso de NotImplementedException

¿Se considera una mala práctica lanzar NotImplementedExceptionun código que aún no has escrito? ¿Posiblemente TODOS los comentarios se considerarían más seguros?

Creo que en NotImplementedExceptionrealidad es una buena práctica.

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

Recomendaría usar los comentarios NotImplementedException combinados con TODO, de esa manera combina la ayuda de la 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 tener un programa aparentemente funcionando correctamente pero produciendo resultados erróneos.

Depende de su filosofía general sobre los errores y el manejo de errores. Soy el tipo de "error duro": lanzaré una excepción al menor indicio 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 hay algo allí, y no debería, todo el universo debe detenerse. El sonido de exclamación de las ventanas debe sonar siniestramente a través de los altavoces.

Hay otras personas que prefieren no molestarse con los errores. Entonces, ¿qué pasa si lo enviamos al cliente y falta el módulo de informes completo porque olvidamos 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 esqueleto que se genera automáticamente a partir de un formulario o diagrama o algo así. La excepción me recuerda que implemente el código, y se asegura de que haya errores si trato de usar la funcionalidad que se configuró pero nunca se implementó por completo. A veces lo rechazo o lo reemplazo con algo que es menos probable que detenga la ejecución (como imprimir una advertencia en la consola), pero descubro que funciona para mí.

Si está construyendo una biblioteca que otros usarán, esta excepción es mejor que la alternativa, que sería un usuario de su biblioteca llamando a una función y preguntándose por qué nada parecía suceder. Por supuesto, todavía es bastante malo tener esta excepción en una biblioteca enviada, pero es mejor que las fallas silenciosas, en mi opinión.

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

Siempre uso NotImplementedException, para eso es, después de todo.

Esto está relacionado con el concepto de "falla rápida": si su código arroja una excepción, eso debería quedar atrapado antes de pasar a 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 voidmétodos, no realiza ninguna acción, entonces 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 un código correcto, su código puede romperse porque depende del comportamiento incorrecto anterior.

¿Qué tipo de proyecto es este? ¿Trabajo u hogar? En casa, haga lo que quiera, lo que mejor le recuerde que necesita terminar lo que sea que esté trabajando.

En el trabajo, termina de escribirlo.

No puedo ver una situación en la que registre el código que puede / romperá otros desarrolladores, QA o una compilación.

Hago ambas cosas pero a \ todo en mi autoxycing doxygene y luego lanzo la excepción. De esa manera, si las personas no pueden molestarse con RTFM, al menos podrán descubrir por qué su programa se bloqueó, en lugar de preguntarse por qué hay una función declarada que no devuelve un valor lógico.