Reglas: código seguro en .NET

1. Nunca confíes en el input del usuario: Una de las causas más comunes de errores no controlados, el asumir que el usuario ubicará datos congruentes en cualquiera de los mecanismos de ingreso de información. De manera que todo "absolutamente todo" es validado a todo nivel, desde las formas ASP.NET hasta la capa de datos.
   
2. Nunca permitas que la interfaz de usuario "se caiga": El usuario no debería perder la interacción con la aplicación. Si se llegase a generar una excepción, no debería ser el fin del mundo!, de esta manera tratamos de informarle al usuario: Qué paso? Qué tipo de excepción es?, Por qué pudo haberse generado el error? y Qué puede hacer para remediarlo?: Si es un error de input que ubique los valores adecuados o si es un error no manejable por el usuario a quién tiene que contactar para resolverlo.
   
3. Capturar la mayor cantidad de excepciones posibles y registrarlas: El poder analizar los métodos dentro de los componentes, datos o presentación clasificando excepciones podría resultar una tarea ardua, pero enriquecedora en cuanto a resultados, mucho más si registramos las excepciones generadas, nos ha ayudado muchísimo a resolver problemas insospechados de forma relativamente rápida y efectiva. Aquí incluyo la clasificación de excepciones: comenzamos entre las "Excepciones Catastróficas" y el "Resto", para priorizar... lógicamente esta división se amplió a categorización por módulo, importancia, frecuencia, etc.
   
4. Verificación de nulidad de objectos: Asumir que el objeto (sea control, instancia de clase, etc) podría ser nulo ("null") en cualquier momento. Esta estrategia te libera de muchos problemas derivados de la omisión.
   
5. Implementar mecanismos de reporte de Bugs: Una vez que la aplicación está en producción, al usuario detectar un bug o excepción, tiene la posibilidad de reportarlo mediante mecanismos de comunicación con nuestro departamento de soporte. Esencial en aplicaciones de alto desempeño. Seamos razonables, la aplicación libre de bugs no existe, por lo tanto lo mejor es tratar de manejarlos, reportarlos e incluirlos dentro del flujo de soporte. Muy buenos resultados, sobre todo hacia la imagen que damos al usuario.

Autor: JavierRomero Temperamental .Net Developer