Lanzar NotImplementedException en el caso predeterminado en la instrucción switch

Question

¿Debo arrojar un NotImplementedException() en default, si tengo casos para todos los posibles tipos de enumeración?

Answer 1

Si está buscando un valor que debe, por definición, corresponde al valor de una enumeración, y ha recibido algo más, definitivamente es un argumento no válido.

Pero ahora debes considerar el contexto.

¿El método es privado y solo es accesible para los miembros de la biblioteca o aplicación de la clase? Si es así, es un error de codificación que, para empezar, NUNCA debería ocurrir. Assert y fail.

Si, por otro lado, es un método público o protegido, y puede ser accedido por los clientes que consumen su biblioteca, definitivamente debe lanzar con un mensaje significativo (y preferiblemente un tipo de excepción bien conocido).

Es importante recordar que las enumeraciones no están verificadas en el marco. Puedo especificar que un método requiere un parámetro de tipo Environment.SpecialFolder; pero aceptará cualquier valor entero de 32 bits.

Por lo tanto, en resumen, si su método es para el consumo público, sí, por supuesto, tiro. Si no es para el consumo público, Assert.

Answer 2

Realmente depende del proceso específico, pero sí, es un buen proceso para responder de manera predeterminada: caso si se supone que algo no debería estar allí.

Answer 3

Eso suena como una opción razonable.

Personalmente, crearía un nuevo tipo de excepción (tal vez un InvalidEnumException o le daría otro nombre que tenga sentido para el equipo de soporte) y arrojar eso.

Answer 4

Yo arrojaría ApplicationException porque si su código llega al valor predeterminado y no lo esperaba, esto significa que algo en su código no se está comportando como pensaba.

Answer 5

Yo diría que al menos debería poner allí un Debug.Fail().

Debe lanzar una excepción en caso de que el método de ninguna manera pueda continuar. Pero si es como convertir sus valores enum a representaciones de cadena, entonces puede simplemente devolver alguna cadena de advertencia. El producto no se bloqueará en los usuarios debido a un error obvio, probablemente habrá una solución y todos estarán felices.

Answer 6

Quizás no NotImplementedException, pero ArgumentException. Realmente dependería de dónde lo estés usando.

Answer 7

Realmente depende de su caso de uso. Será útil si lanza una excepción durante los primeros días de la integración. Los usuarios de su biblioteca pueden conocer inmediatamente los errores

Answer 8

Si lanzó la excepción ¿qué pasaría? ¿En qué contexto se está ejecutando la instrucción switch? ¿Debería ocurrir esa situación alguna vez? ¿Debería ocurrir alguna vez en tiempo de ejecución en el código de producción? ¿Sus pruebas unitarias cubren esta situación? Si es así, quizás una afirmación sería mejor.

Answer 9

Primero debe considerar lo que significaría si obtiene un valor fuera de los casos conocidos: ¿qué representa la variable que se enciende? Entonces, simplemente puede usar un tipo de excepción que se ajuste a lo que realmente está sucediendo.

Answer 10

Realmente depende.

• El NotImplementedException es algo así como todo marca para mí. Significa que alguien vendrá después para terminar el código. Sin embargo, no creo que sea un caso de incumplimiento que no debería suceder.

• Cuando esté comprobando el estado del objeto, puede considerar InvalidOperationException. Su método está diseñado solo para trabajar con casos existentes.

• Cuando se discrimina sobre el parámetro de entrada ArgumentException siempre es apropiado.

• En otros casos prefiero NotSupportedException. Indica levemente que algo está mal con la plataforma o la versión. Y las versiones incompatibles del código son la verdadera raíz del problema cuando ocurre un caso de cambio predeterminado que no debería suceder.