Otra cosa curiosa, la inmutabilidad de los Strings.
Me di en la frente con este tema al intentar hacer que un método me devolviese dos argumentos de tipo String.
Ejemplo:
void MiMetodo(int arg1,String argOut1,String argOut2)
{
//... realizo operaciones
/*Modifico argOut1 y argOut2 para devolver el resultado.
¡Error!, ¡los Strings son inmutables!*/
argOut1 = "resultado";
argOut2 = "resultado2";
}
El problema es que al ser inmutables cada vez que asigno algo a un string se crea un objeto String nuevo y estas nuevas referencias a los nuevos objetos no la pueden “recoger” los llamadores al método.
Curioso… al final usé StringBuilder y ya está. Pero me resulto curioso el tema este de la inmutabilidad de los strings.
Supongo que serán inmutables por algún tema de eficiencia, ¿?.
Archive for November, 2009
Programando en java, impresiones (II)
Monday, November 23rd, 2009XML-Schema en dos patadas
Monday, November 16th, 2009Lo dicho, aprendiendo lo básico de xml-schema en dos patadas aquí.
Programando en java, impresiones (I)
Monday, November 9th, 2009En el trabajo ahora me ha tocado programar en Java, esto resulta estimulante, llevaba muchos años programando C/C++ y un cambio de aires siempre viene bien.
El caso es que al ir re-aprendiendo Java (en realidad sabía Java hace 10 años cuando salí de la facultad, pero es sorprendente lo rápido que se olvidan las cosas si no las usas) hay cosas que me llaman la atención, como la siguiente:
public int generateLINDownload(int fareVersion) throws Exception
{
// código ....
File file = File.createTempFile("lines", ".xml", tempDir);
try {
// .. más código
return llamada_a_funcion();
} finally {
file.delete();
}
}
Lo que me sorprende es el trozo de código encerrado en el último “finally”. Curioso…. siempre he contemplado las excepciones como un “goto” encubierto con jerga de orientación a objetos y efectivamente cada vez estoy más convencido de ello. No es algo que me moleste, yo los utilizo, con sumo cuidado, en ciertas partes de mi código C. Lo que me divierte del asunto es la gente que se tira de los pelos cuando ve un “goto” en tu código y luego programa cosas como esta y se queda tan pancho (hay que ver cuanto daño hacen los dogmas aprendidos en la facultad sin reflexión alguna).
Yo entendía que este “finally” se ejecuta siempre, vaya bien o mal el trozo encerrado entre el “try” y el “catch”, y hombre, a mi me mosqueaba ver un “return” y pensé ¿que pasa, no se borra el fichero al haber un return?. Pues mire usted por donde, el finally, ¡se ejecuta también si hay un return!.
Vaya a esto le llamo yo una interrupción de la secuencialidad del código. Como un goto o algo más rebuscado si cabe.
Curioso, cuanto menos….
