2012-06-01 8 views
10

Me doy cuenta de que tiene beenamplediscussion de los méritos relativos de las excepciones comprobadas frente a las excepciones no verificadas en Java, y no es mi intención volver a visitar todo el debate.excepción no comprobada que hubiera sido mejor como comprobada

Por el contrario, me gustaría hacer una pregunta muy específica que me vino a la mente mientras leía Effective Java, 2nd Edition de Joshua Bloch. Mientras leía, noté que en el Ítem 59 ("Evite el uso innecesario de excepciones comprobadas") Joshua da un ejemplo en la API de Java donde se usa una excepción marcada. En concreto, en Object:

protected Object clone() 
      throws CloneNotSupportedException 

... y luego argumenta que debería haber sido una excepción no comprobada su lugar.

Si el programador que usa la API no puede mejorar, una excepción sin marcar sería más apropiada. Un ejemplo de excepción que no supera esta prueba es CloneNotSupportedException. Lo lanza Object.clone, que debe invocarse solo en los objetos que implementan Cloneable (Elemento 11). En la práctica, el bloque de catch casi siempre tiene el carácter de una falla de aserción. La naturaleza verificada de la excepción no proporciona ningún beneficio al programador, pero requiere esfuerzo y complica los programas.

Luego miré para ver si tenía un ejemplo de lo contrario, pero no pude encontrar uno.

Así que me gustaría preguntar si alguien puede dar un ejemplo de API en Java que utiliza una excepción sin marcar, pero donde una excepción marcada hubiera sido una mejor opción, y explicar por qué. Sería preferible un ejemplo del mundo real, pero estoy abierto a un ejemplo artificial si eso ilustra también las cosas.

Editar: Para aquellos que han votado para cerrar esto como no constructivo, quiero dejar en claro que no estoy buscando opinión, debate, argumento o discusión extendida. Tampoco estoy tomando una encuesta. Más bien, estoy buscando referencias a ejemplos que arrojen un análisis claro de cómo los beneficios superan los costos. (Implícito en eso es reconocer que hay costos.) Dicho esto, soy escéptico sobre si la naturaleza de esta pregunta lo hace posible. Creo que si Jon Skeet no puede hacerlo, es poco probable que se pueda hacer. Entonces quizás tengas razón. Cierra si es necesario.

Edit: Aunque no me conmueve la respuesta, voy a adjudicar esto a Jon solo por mi tasa de aceptación.

Respuesta

13

Sí, fácilmente: Integer.parseInt arroja NumberFormatException que no está marcada.

Sin embargo, si alguna vez está analizando datos potencialmente malos, definitivamente debe considerar detectar la excepción; es muy posible que pueda ignorar esos datos, o tal vez informarlos y seguir adelante. No es que Java tenga un equivalente de .NET Int32.TryParse que le permite fácilmente ignorar datos incorrectos. Básicamente, necesita saber que necesita detectar la excepción, sin la provocación del compilador. Grr.

+2

Estoy totalmente de acuerdo. Cuando está codificando e ingresa "la zona" es bastante fácil perder esa cierta excepción que está esperando a aparecer y gritar "pwn3d!" ya sea porque olvidó atraparlo o porque no sabía que podría necesitar atraparlo ... – Gamb

+0

Gracias por su respuesta rápida, Jon. Has elegido un ejemplo que no me molesta. Estoy satisfecho de que la excepción se menciona en JavaDoc, y agradezco que pueda elegir el ámbito en el que manejar las cuestiones.¿Cree que cada ejemplo se reducirá a la misma compensación? – pohl

+0

@pohl: Supongamos que * llama * 'Integer.parseInt' en uno de sus métodos, pero se olvida de atraparlo o declararlo. En ese punto, las personas que llaman del método * that * no tienen idea de lo que podría pasar. Aún feliz con esa situación? –

Cuestiones relacionadas