Jan 4, 2012

El colmo es tener que interpretar mensajes de error

Noventa y nueve por ciento de las veces que me encuentro algo que no funciona es mi culpa. No soy de los que anda echándole la culpa al Visual Studio .NET porque mi código no compila. Yo sé que hice algo mal, así que lo busco, lo resuelvo, y punto en boca.

Repito, 99%. Tengo que darme el beneficio de la duda muchas veces, pero reconozco que son contadas.

Sin embargo, el VS.NET sí es pésimo explicándome por qué y en qué me estoy equivocando. Muchas veces entiendo que un mensaje de error específico es técnicamente complejo de determinar, pero otras me dan simplemente ganas de vomitar.

Si el problema es que estoy forzando que 2 + 2 sea igual a 5, cualquier otro mensaje diferente a "imbécil, 2 + 2 nunca es 5" es simplemente una mierda y no ayuda para nada. Si el error es en la primera línea del fichero "A", es inadmisible que el compilador señale la línea 385 del fichero "C".

Ejemplos sobran. Todos los días se puede adicionar uno a la lista.

Que VS.NET sea tan jodidamente malo en esto no me molesta; es su problema. Que haya personas que lo defiendan diciendo que los desarrolladores tenemos que saber "interpretar" estos errores me revienta de veras. Si tú dices "rojo", ¿tengo yo que asumir que es "azul"? No me jodas.

Mientras VS.NET siga mostrando adivinanzas, pues tendremos que seguir adivinando, eso queda claro. Pero el que piensa que eso es correcto, que piense de nuevo. 

Cuando diseñen sus propios sistemas, por favor, no hagan que los usuarios "interpreten", "adivinen", o se vean obligados a usar Google para corregir un problema que ustedes mismos pueden indicar con un mejor manejo de excepciones. Háganlo de la forma en que se supone que lo deban hacer.