Capturando excepciones no manejadas

Un bookmark que guardo desde hace tiempo es una entrada del blog de Bruno Capuano (blog recomendado) donde explicando como abordar el problema de la “Big Red Cross”, me descubrió la forma de forzar a un WinForms a que maneje todas las excepciones en lugar de que tire la aplicación cuando se escape una. El ejemplo esta sacado de su blog, consiste en añadir en Program.cs el manejo de dos eventos relacionados con las excepciones e indicar que se fuerce el manejo de estas. Efectivamente hasta lanzando una OutOfMemoryException (catástrofe de las catástrofes) desde el código del formulario es “cazada” y mostrada en un MessageBox sin que la aplicación se caiga. Esto no solo es útil desde este punto de vista, pues si salta una excepción es que algo grave pasó (recuerda que es mejor no ir lanzando excepciones al a torera) y de esta forma podríamos logear el motivo.

Excepciones y rendimiento en .Net

Vía el blog de novaxo descubro un artículo (algo antiguo) sobre la rapidez de .TryParse() sobre .Parse(), ya que el primero evita las excepciones. Que las excepciones afectaban al rendimiento de la aplicación era algo ya bastante conocido, pero como dice el autor en el artículo… ¡WOW! Ya había leído un artículo interesante sobre las excepciones y el rendimiento en CodeProject, donde las conclusiones fueron que se deberían usar únicamente en situaciones anormales ó como control en operaciones con resultados erróneos, nunca como una forma de control rutinaria. En MSDN, cualquier artículo referente al rendimiento de aplicaciones .Net tanto desktop como web, hace referencia al tema de las excepciones. En la guia Improving .NET Application Performance and Scalability dejan bastante claro cuando usar las excepciones. En este otro artículo algo más antiguo (casi 6 años solo ) también lo dicen claro, throw fewer Exceptions.