Buenas tardes
Estoy realizando el tp de java, y me encontré con los siguiente problemas:
Warning: assertEquals( double expected , double actual ) is deprecated.
para evitar este warning hay que agregar el DELTA, como un tercer argumento.
Realizando el calculo de manipulación de fechas usando las librerías de java.util.*.. el IDE (intelij en mi caso) te pide agregar la siguiente Exception
Error: java: unreported exception java.text.ParseException; must be caught or declared to be thrown.
esto se arregla agregando la excepción a los tests.
Esta bien realizar estos cambios ?
Gracias.
Hola Esteban,
En cuanto a lo primero, es simplemente una advertencia que podés ignorar. En el único lugar donde sería necesario ese tercer parámetro es en el primer assert de la primera prueba, que ya modifiqué agregando el DELTA. En el resto no debería aparecer el mensaje porque, o ya tienen el DELTA o son asserts de valores enteros.
Respecto a lo segundo que mencionás, no es el IDE el que te da ese error, sino el compilador de Java (javac). Lo hace porque ParseException es una excepción de chequeo estático, es decir, que estás obligado a atraparla en alguna parte. Deberías encerrar entre try y catch la parte de código del parseo de fechas que tiene la posibilidad de lanzar esa excepción. Una vez que la atrapes podrías, bien no hacer nada, o bien lanzar una excepción tuya que sea de chequeo dinámico (debe heredar de la clase RuntimeException en lugar de Exception).
En Smalltalk esto no era necesario porque las excepciones no eran verificadas antes de la ejecución pero a los tipos que hicieron Java se les ocurrió hacerlo distinto para hacerlo "más seguro", pero a su vez hace que, en mi opinión, sea mucho más molesto.
Hay más información sobre esto en el capítulo 9 del libro y en esta presentación que se usó en una clase teórica.
Saludos,
Tomás
Genial, gracias.
Hola Tomás:
vi que cambiaron esa línea en los tests. El tema es que también estarían fallando los asserts de las líneas 16, 32, 66, 84, 100, 123, y 203 (les faltaría el 3er argumento "DELTA" tengo entendido).
¿Esperamos a que suban la versión corregida?
Gracias,
Santiago.
Hola Santiago,
No, en esas líneas no va el DELTA porque se está comparando números enteros. En esos casos se hace uso de este método:
public static void assertEquals(int expected,
int actual)Para los casos de comparación de números fraccionarios usamos el siguiente, que es un método distinto:public static void assertEquals(double expected,
double actual,
double delta)Saludos,Tomás
Ah cierto, ahí entendí y anduvo bien. Gracias!
Buenas,
Me surgieron una par de dudas al leer las consultas:
Estuve leyendo el texto de apoyo conceptual que adjuntaron y comprendí un poco mejor el funcionamiento de las excepciones en java. Mi duda es si se espera que nosotros usemos específicamente alguno de los dos tipos de excepciones. Si usásemos ambos tipos de excepciones de forma correcta, ¿cambiaría algo para la aplicación de nuestro tp que usáramos uno o el otro?
Además, no me termina de quedar claro el propósito de las excepciones de tipo estático. ¿La única diferencia entre ambos tipos de excepciones es que una es más robusta e implica que se la atrape si o si y la otra no?
Saludos!
Hola Mauricio,
La diferencia es que las excepciones chequeadas hacen que el programa sea más seguro, dado que no compilará a menos que en alguna parte se atrape esa excepción. Las otras, en cambio, permiten que se compile el programa y que, si el programador no se avivó de atraparla en algún lado, al lanzarse se interrumpe la ejecución del programa mostrándole al usuario un mensaje muy poco ameno.
Por lo general el criterio de diseño para utilizar unas u otras es el siguiente:
- Excepciones chequeadas para todo tipo de situaciones que se puedan predecir y de las cuales se pueda hacer algo para continuar con el funcionamiento del programa, es decir, para las que están relacionadas con el negocio o el dominio del programa.
- Excepciones no chequeadas: para todas las otras situaciones, es decir, aquellas que no se pueden predecir y que, en caso de suceder, no hay punto de retorno y no tiene sentido atraparlas. Por ejemplo algún error de memoria, de base de datos o de alguna cuestión relacionada más con el entorno que con el dominio del programa.
Clarísima la respuesta Tomás,
¡muchisimas gracias!
Mauricio.