Poner bonito try/catch

[moisesvs]

Hola a todos, os comento un problema que tengo, tengo un código que lo tengo bastante limpio y demás, pero al añadir los try/catch que produce cada método y alguna llamadas a cada uno, el código se "estropea" y se afea bastante, hay alguna forma de mejorar esto, y que los try/catch de java no afecten tanto a la lectura del código.

Gracias!

[HackmanC]

Hola,

Iniciado por moisesvs

... el código se "estropea" y se afea bastante, hay alguna forma de mejorar esto, y que los try/catch de java no afecten tanto a la lectura del código. ...

Entonces ... no los pongas !!!
(Es broma)

Creo que tienes toda al razón, una de las características que más llama la atención a los programadores en Java es su sintaxis, al programador en Java, normalmente, no le preocupa tener que escribir muchas palabras en favor de un código limpio y elegante. Al contrario de otros lenguajes criptográficos.

No es obligatorio, pero creo que un código bien organizado es más eficiente y optimizado. Al compilador no le va a importar que hayas escrito todo el programa en un sola línea, va a generar el mismo código objeto. Pero un código bien organizado normalmente está mejor pensado.

Pero habría que ver el código que escribiste para saber realmente el motivo por el cual 'se afea', puesto que siguiendo algunas técnicas logras obtener código sumamente ordenado y funcional. Aunque no siempre se logra, por lo menos lo mejora.

En lo personal, inclusive busco sinónimos en los nombres de las variables que se ajusten a la misma cantidad de letras, eso inclusive te facilita en el momento de la depuración.

Habría que ver el código para saber como se puede mejorar en presentación, y si realmente es posible,

Saludos,

[GreenEyed]

Seguramente el problema sea que pones demasiados try/catch, uno por cada método susceptible de lanzar alguna excepcion del tipo checked, cuando lo normal es agruparlo por bloques donde te interese o haga falta tratar las excepciones.

En cuando al código, no es "bonito" ni "feo", más que en cuanto a si hace lo que debe hacer y es fácil de mantener, comprensible etc. Si hacen falta mas "letras" o bloques para eso, pues se ponen. Java es algo verborréico, totalmente de acuerdo, pero es lo que tiene y hay que adaptarse a su estilo, como hay que adaptarse a cada lenguaje.

S!

[moisesvs]

Gracias por vuestras dos respuestas!

[Fuzzylog]

Con un try para todo el código (de un archivo .java) y diferentes catch para los errores más comunes, y un finally si lo precisas, llega.

Ej:

try {
//Todo el código
}
catch(NumberFormatException nEx( {
//Muestra un mensaje - debe ingresar un número
//Reenvias a una jsp o UI con el mensaje que se muestra en un campo de texto donde deberia ir el numero, como una calculadora.
}
catch(Exception Ex) {
//Muestra un mensaje de error general. Tb. lo puedes ingresar en la jsp o UI pero en otro lado.
}

[GreenEyed]

Con un try para todo el código (de un archivo .java)..., llega

Exceptuando el "hello world" y sus amigos, no recuerdo jamás haber escrito una sola clase en la que fuera adecuado meterlo todo en un único bloque de código.
Que lo puedas hacer no quiere decir que sea lo más conveniente. .

S!

[elAntonie]

Wenas

Opino como greeneyed.

Quizas a 'todo el codigo dentro de un try/catch' te refieres, por ejemplo, a todo el codigo de un metodo de la clase.

Pero todo el codigo de la clase, no me parece muy conveniente, desde luego.

Saludos.

[moisesvs]

Me refieria a que existen muchos metodos que necesitan de try/catch y eso hace que el programa sea mas feo y dificil de leer.

No se si se podría hacer algun método que hiciera captura de algunas excepciones.

[elAntonie]

Hombre, siempre puedes lanzarlas hacia arriba con un throws, pero la gracia de las excepciones, es capturarlas donde han pasado (hablo, claro esta de excepciones graves que implique un fallo en el proceso), sin contar con que puedes hacer cosas con ellas, y poder redirigir la aplicacion. Me explico

Por ejemplo, un metodo que te devuelva un entero y le pasas un string. Si es algo del estilo.

Código:

public int setEntero(String num) throws NumberFormatException
{
int retorno = 0;
retorno = Integer.parseInt(num);
return retorno;
}

Si a este metodo le llamas con setEntero("pepe"); te mete un buen cascotazo, y si ni siquiera lanzas NumberFormatException y estamos hablando de un proceso, de los 'bonitos' adivina donde esta el problema.

Pero si este metodo lo sustituyes por

Código:

public int setEntero(String num)
{
int retorno = 0;
try{
retorno = Integer.parseInt(num);
}catch (NumberFormatException)
{
System.out.println("estas tonto o que?");
}
return retorno;
}

Te devolvera siempre un numero. Aparte de insultarte un rato.
El que sea mas bonito o mas feo, es como los colores.

Saludos.

[Fuzzylog]

Cierto GreenEyed, yo le suelo meter un try al menos a todos los métodos. Algunos necesitan más de uno, pero me refería a englobar partes enteras, no a poner try catch cada vez que haces algo que pueda hacer saltar excepciones distintas.

[GreenEyed]

Pues yo no lo miro tanto. Los pongo donde hacen falta para tratar las excepciones donde deben ser tratadas y ya está. Si sale 1, 2 o n por método no me preocupa. El que salgan muchos o pocos es consecuencia de programar bien, pero no es un fin.

S!

[moisesvs]

Si mas o menos yo trato cada excepcion en los metodos, pero por ejemplo si estas programando un sistema de Redes, cliente servidor, te puede dar Excepciones de mil tipos.

IOException,ClassNotFoundExcepcion,HostUnko... las propios excepciones definidas por mi.

La pregunta que hacia, era si todas esas excepciones que lanza un metodo se podría englobar en un mismo CATCH es decir, puede que diga una chorrada, pero algo del estilo.

(IOException e, ClassNot...)

Si se que se puede coger Exception e y ya esta, pero me refiero a que si se podría generar un metodo que el sepa manejar excepciones, por ejemplo una clase que se llamara manejadora de excepciones, y se invocara a ella cada vez que produce una excepcion.

Saludos!

[HackmanC]

Hola,

Yo me refería a algo muy diferente ... cosas de estilo ... nada mas,

Iniciado por elAntonie

...

Código:

public int setEntero(String num)
{
  int retorno = 0;
  try{
    retorno = Integer.parseInt(num);
  }catch (NumberFormatException)
  {
    System.out.println("estas tonto o que?");
  }
  return retorno;
}

...

Código:

public int setEntero(String strNumero) {
  int intValor = 0;
  try {
    intValor = Integer.parseInt(strNumero);
  } catch (NumberFormatException e) {
    System.out.println("estas tonto o que? :risa:");
  }
  return intValor;
}

En ese caso los '{' del try están siguiendo el mismo formato, k&r, stroustrup o java. Y creo que es más legible de esa forma. Pero como dice GreenEyed ... hay que ponerlos donde hace falta, ... no más, no menos. Y como dijo elAntonie; para gustos los colores.

Iniciado por moisesvs

... Si se que se puede coger Exception e y ya esta, pero me refiero a que si se podría generar un metodo que el sepa manejar excepciones, por ejemplo una clase que se llamara manejadora de excepciones, y se invocara a ella cada vez que produce una excepcion. ...

Algo así como:

¿On Error Goto subHandler?
¿ON ERROR DO fnTRAPERR WITH MESSAGE()?
¿set_error_handler (callback)?

Suena a Visual Basic 6, Foxpro 6, o PHP 4 ... hace como 10 años.
Aunque posiblemente se pueda hacer en Java
Habría que preguntarle a GreenEyed.


Por lo demás, yo no capturo excepciones, las tiro hacia arriba, a menos que pueda corregirlas eficientemente en ese mismo procedimiento. Es parte de la GUI encargarse de mostrar el error y cancelar el procedimiento o eventualmente ofrecer una opción diferente.

Usando el mismo ejemplo de elAntonie (public int setEntero), si no es un numero, muestra un mensaje de error, pero el procedimiento principal ni se enteró del error. Si hubiera tirado el error, el GUI tendría la oportunidad de preguntar ¿No es un número, desea intentar de nuevo o cancelar?. Por supuesto que es un ejemplo demasiado simple.

Pero esa solamente es mi opinión,
Saludos,

[GreenEyed]

En Java 7 quizá añadan los catch multiples, estilo "catch(IOException, JDBCException.... e)" pero los "handlers externos" no existen.

Y de hecho no suelen tener mucho sentido, ya que necesitas el contexto para tratar las excepciones como es debido. Si lo que quieres es llamar siempre al mismo metodo, pues es muy fácil.

En cuanto a tratarlas o lanzarlas... pues depende. El mismo caso del número que se ha mostrado aquí se puede tratar de varias formas dependiendo de lo que signifique el número.

Ese mismo caso lo he tratado diferente si era un numero que introducía un usuario para algo, por lo que normalmente se cambia la excepción por otra, se lanza para arriba y se le muestra el mensaje adecuado al usuario, o si era un numero de una configuración para un proceso batch donde hay un valor por defecto, y ahí simplemente se escribe una traza de error para avisar que el parametro está mal y se continua con el valor por defecto por que no se puede parar el batch por ese error de configuración.

Así que no creo que haya un criterio único, aparte de que el código funcione como toque.
S!