Los 10 errores responsables del 97.3% de los fallos en producción en aplicaciones Java

Tapiki recientemente ha publicado en su blog una entrada celebrando un hito dentro de la compañía: acaban de analizar su error número 1000 millones en producción. Estos errores surgen de más de 1000 aplicaciones en producción que están empleando el software de Takipi para monitorear estas aplicaciones.

De entre estas aplicaciones, han sacado una serie de estadísticas interesantes. Por ejemplo, la aplicación promedio de entre estas 1000 generaba 9,200,000 errores al mes, habiendo entre estos errores 53 tipos de error diferentes. Y requería 2700 GB de almacenamiento. Los 10 errores más frecuentes, ordenados por frecuencia de mayor a menor fueron:

• NullPointerException
• NumberFormatException
• IllegalArgumentException
• RuntimeException
• IllegalStateException
• NoSuchMethodException
• ClassCastException
• Exception
• ParseException
• InvocationTargetException

 ¿Coincide vuestra experiencia con este listado? ¿Hay algo que os llame la atención en el?

Comments

[Kenyi_java]

No estoy de acuerdo, esos errores surgen debido aque no validan su codigo!!!
Yo llevo muchas aplicaciones en produccion con grandes volumenes de informacion y no he tenido esos problemas debido a que valido muy bien mi codigo!!!

[MAF]

Enhorabuena Kenyi_java has alcanzado el Nirvana de los desarrolladores: Proyectos sin fecha de paso a producción fijada sin analizar el proyecto.

[Jesus Perales]

Excelente información, los errores siempre estaran presentes en un sistema, la unico que nos queda es tratar de minimizarlos y supongo que coincido con la estadistica.

[nilojg]

Pues a mi me llama la atencion el "NoSuchMethodException". ¿Tanta reflection se usa por ahi?

[enyels]

Estoy totalmente de acuerdo contigo MAF, yo tambien te felicito "Kenyi_java", respecto al post los dos primeros son errores que veo continuamente saludos a todos.

[ajaristi]

Muchos de estos errores se deben a que muchas veces no usamos (o usamos mal) frameworks. Por ejemplo SpringMVC ayuda mucho en los binding y JSF con sus validators nos quita muchos dolores de cabeza.
Respecto a los ClassCastException, sale mucho cuando usamos AOP, por ejemplo, como lo hace Hibernate.

[luis]

Resumen ejecutivo (validación de vista, validación de base de datos, validaciones en el medio no)
En aplicaciones web actuales
Me parece un gran sin sentido estar poniendo código de validación el resultado neto de no hacerlo es que se meta en el log en caso de error y que el servidor no se caiga
El resultado neto de validar si se hace bien es que se meta en el log en caso de error y que el servidor no se caiga (cosa que nunca pasa la mayoría lo hace mal porque no conocen bien el lenguaje y no saben matemática nivel escolar) en el resto de los casos solo se oculta el error y aumenta el ego del programador que dice tener el log limpio
Por esos motivos yo evito validar lo más posible
Las únicas validaciones que creo relevantes son para la fuente de datos las cuales permitan que no se grabe datos corruptos de forma permanente
Mi metodología es la siguiente
no valido si hay error dejo entrar en el log de todas maneras
si encuentro un error veo quien lo origino y lo soluciono de raíz (el que entrega el dato erróneo, arreglar el que lo recibe no tiene sentido)
Hago todas las validaciones de base de datos posibles para que no ingrese datos corruptos de forma permanente
hago solo validaciones en el lado del cliente en javascript para hacer que el usuario no pueda siquiera escribir datos inválidos

dependiendo como manejan los errores (en la mayoría de casos como no lo manejan o lo manejan pésimo) usualmente imprimen varios errores encadenados por ejemplo un
RuntimeException es causado por un IllegalArgumentException causado por un NumberFormatException causado por un elProgramadorEsElErroException ese es el motivo por la cual los primeros errores están en la lista

si logras hacer que corra un framework mal configurado o logras usarlo mal , el framework inflara de errores con el log lo cual no quiere decir que tu aplicación tenga errores graves solo que esta mal configurada

la validación de código es una de las más grandes farsas que se han contado. la mayoría de las validaciones son muy malas y muestran una gran desconocimiento de temas básicos que todo programador (incluso estudiantes de secundaria)debería conocer como algebra booleana , matemática básica, mal uso de las formas normales ,teoría de conjunto y una gran falta de criterio

la mayoría de la gente que valida su código sabe muy poco de cómo funciona las exeception por lo cual lo único que hace es esconderlas pensando que las está validando o la vuelve a mostrar perdiendo parte de la traza y/o toda información relevante del error ejemplo de cómo se maneja los errores de producción

try{
enErrorSePierdeCosasImportantes();
}catch(Execption e){
//a qui se manejan las excepciones no olvidar siempre manejar las excepciones para
//seguir las buenas practicas de programacion
e.printStacktrace();
}

try{
horribleMetodoQueNoMePermiteCompilarNoSePorQuePeroSOmerecomienadausartrycatch();
}catch(Execption e){
//Todo autogenerted by ide
}
La mayoría tiene 0 criterio y sentido común no usan lo básico de álgebra booleana https://blog.codinghorror.com/flattening-arrow-code/ por lo cual ponen un montón de if else anidados uno dentro de otro incluso para rematar usan break y continuo por si las dudas (crean me lo he visto todo el tiempo) ejemplo de como se ve el codigo de producción de las mayorías de aplicaciones

SuperCoolFrameworkConAutocomit sc=null;
if(sc==null){//!!importante validacion si no no corre
sc=crearSuperCoolFrameworkConAutocomit()==null?otroMetodo():null;//validacion si //no corre
}
sc.setAutocomit(new Boolean(Boolean.FALSE));
try{
Producto p=new Producto(nombre,precio,"categoria_en_duro");
if(p!=null){
if(p.getCategoria()!=null)
if(p.getNombre()!=null)
if(p.getPrecio()!=null)
if(noSoyAteo()&diosExiste()) //ojo una sola &
try{sc.persist(new Producto(nombre,precio,"categoria_en_duro"))}catch(Execption e){}
}
Sc.commit();

}cath(Exception e){
sc.roolback();
}finaly{
sc.close();//te olvidaste
}

Creo firmemente (tanto como sale el sol) que la mayoría de validaciones que se escribieron son inútiles
El resultado neto de poner un try catch o un if mal puesto no soluciona el error solo lo esconde y aumenta el ego del programador que puede decir falsamente que su log está limpio
Estamos en el siglo 21 muchos de nosotros trabaja con servidores web y todos ellos son resistentes a los errores ninguno se muero por un indexoutofboundsexception y lo mejor que se puede hacer es solucionarlo de raíz a la hora de programar y en caso de que haya error permitir que se incruste como evidencia de un crimen en el log para luego hacer un análisis post morten con evidencias completas claras y reales