¿Es una buena práctica usar excepciones para manejar casos que no son errores?usando excepciones para propósitos que no sean errores
Me gusta en JavaScript y Python que administran el caso de StopIteration en generadores (palabra clave de rendimiento).
Depende del idioma. Cada idioma tiene su propio diseño y modismos. Para la mayoría de los idiomas, las excepciones deben ser excepcionales.
En idiomas como C++, Java y C# es muy malo utilizar excepciones para cualquier otra cosa.
En Python, las excepciones se utilizan con más frecuencia para cosas como el final de una iteración. Hay mucho más de un modelo de intentar hacer lo que quiera y manejar las excepciones más tarde en lugar de validar la entrada ("Más fácil de pedir perdón que permiso"). Por ejemplo, si desea abrir un archivo, en Java puede verificar si existe primero y luego abrirlo y verificar si tiene una transmisión válida. En Python lo abrirías y lo usarías. Si eso falla, maneja la excepción.
Desde el artículo wikipedia:
llamadas de estilo de Python para el uso de excepciones siempre que podría surgir una condición de error. En lugar de probar el acceso a un archivo o recurso antes de usarlo, es convencional en Python seguir adelante e intentar usarlo, capturando la excepción si se rechaza el acceso.
Las excepciones también se pueden utilizar como un medio más general de transferencia de control no local, incluso cuando no se trata de un error. Por ejemplo, el software de la lista de correo Mailman, escrito en Python, usa excepciones para saltar de una lógica de manejo de mensajes anidada profundamente cuando se ha tomado la decisión de rechazar un mensaje o mantenerlo para la aprobación del moderador.
Yo diría que no, espontáneamente. Se deben usar excepciones para estados excepcionales, no para flujo de programa regular.
A veces no es tan fácil distinguir entre casos excepcionales y regulares. –
¿Te importa dar un ejemplo? – tomfanning
@Suobok No sé cuándo la distinción sería difícil. ¿Puedes dar un ejemplo de un caso donde las líneas se difuminan entre el caso regular y el caso excepcional? –
Normalmente, no. ASP.NET usa esto para Response.Redirect - abortando realmente el hilo, luego capturando la excepción y restableciéndolo. Es muy desagradable, pero es lo que le permite "cerrar" la solicitud sin que todos los niveles de la pila sepan que debe volver de inmediato.
Intente evitar siempre que sea posible. Si cree que absolutamente tiene para hacerlo, consulte a dos colegas, presente el diseño y pregunte si pueden hacerlo de manera más limpia de alguna manera. Si ninguno de ustedes puede pensar en una mejor manera de evitarlo, hágalo con una extensa documentación.
Quizás a veces arrojar una excepción es más claro que una gran cantidad de declaraciones "de retorno" anidadas? –
@Soubok: Hmm ... Muy raramente. Sería una situación bastante "excepcional", para ser honesto. Realmente trataría de evitarlo en todas las situaciones normales. –
Downvoter: ¿le importa un motivo? –
Como su nombre indica, las excepciones solo deben utilizarse en casos excepcionales. No lo usaría para gestionar casos que no sean de error.
Nº
excepciones sólo deben utilizarse para situaciones excepcionales (como su nombre lo dice). Eso significa: errores.
A veces, no poder encontrar un archivo tampoco es excepcional. Especialmente si el archivo es ingresado por el usuario. Ahora, si es un archivo que NECESITA y si no está en un solo lugar, es un signo de problemas, eso es una excepción. –
En las entrañas de su aplicación, sigue siendo una excepción, por supuesto, debe embellecerla antes de mostrársela al usuario. – Bombe
Nº
En general, el sistema está diseñado para hacer que los casos de excepción no rápido, mientras que aceptan casos excepcionales, una pérdida de rendimiento Así, un!. muchas excepciones ser arrojado/atrapado será más lenta que las construcciones convencionales.
también hace que el análisis y la comprensión del código más difícil, y la mayoría del código pasa la mayor parte de su tiempo en el mantenimiento.
Solo tenga en cuenta que Python y JavaScript están usando la excepción StopIteration para administrar el final de un generador porque es más económico que llamar a un método en cada iteración para saber si es el final. –
"Generalmente" puede tener excepciones (juego de palabras). – Richard
... y los implementadores de la plataforma pueden trabajar con diferentes reglas (después de todo, pueden modificar la dinámica de la plataforma para adaptarla a la solución). – Richard
es un muy q práctica cuestionable. Si cree que es lo mejor para su situación, asegúrese de documentarlo y comentarlo detenidamente para mantener su WTF/m abajo.
Creo que a veces las excepciones son útiles para la construcción de DSL s. Lo sé, suena raro, pero como muchos idiomas no tienen las características que tiene Ruby (la palabra clave return es opcional porque se devuelve el resultado de la última expresión evaluada), usamos lo que podemos.
Por ejemplo, recientemente he tratado de construir un pequeño marco de pruebas de JavaScript, y quería una forma para que los usuarios de marco para poder decir:
skip();
pending("pending message");
fail("failure message");
en lugar de:
return skip();
return pending("pending message");
return fail("failure message");
Estas funciones serían funciones de la biblioteca que generan excepciones como una excepción SkipTest, por ejemplo. El único lugar recomendado para usarlos es dentro de los métodos de prueba. Estos métodos de prueba siempre se ejecutan en un bloque try/catch donde se trata cada tipo de excepción y, dependiendo de la excepción, el marco toma el paso apropiado.
Este es un ejemplo en el que he usado Excepciones para el flujo de control.
Aquí hay un pequeño ejemplo:
$.it("should offer means to explicitly mark a spec as failed", function() {
$.fail("this spec must fail");
});
En un solucionador de sudokus que escribí, se produce una excepción en el caso del rompecabezas es resueltos.
La función de búsqueda principal, un método privado, desciende al árbol de búsqueda haciendo llamadas recursivas a sí mismo. El caso normal falla al resolver el acertijo, lo que da como resultado un retorno normal al llamante; el caso excepcional es un éxito en la resolución del rompecabezas, en cuyo caso "arrojamos (solución)" hasta una cláusula catch en un método público.
Algo así es una expresión idiomática conocida en Scheme, que utiliza call/cc. Estaba imitando eso en mi programa C++.
Estaría encantado de escuchar las opiniones a favor o en contra de este enfoque.
debe ser wiki de la comunidad. – SilentGhost
Aparentemente, ninguna respuesta toca el uso de excepciones de JavaScript y Python para interrumpir el flujo de ejecución. –