¿Por qué las excepciones marcadas y no marcadas se llaman "la controversia" en el tutorial de Oracle Java?

Soy nuevo en Java y estaba leyendo su documentación sobre excepciones. , y especialmente las Excepciones no verificadas - La página de controversia .

El resultado final dice:

Si se puede esperar razonablemente que un cliente se recupere de una excepción, conviértalo en una excepción marcada. Si un cliente no puede hacer nada para recuperarse de la excepción, conviértalo en una excepción no verificada.

No entiendo el artículo. ¿De qué se trata "la controversia"? ¿Puedes explicarlo en palabras simples?

java api-design exceptions

— ABcDexter
fuente

Posible duplicado de Comprobado vs No verificado vs Sin excepción ... Una mejor práctica de creencias contrarias

— mosquito

ver también: En Java, ¿para qué sirven las excepciones marcadas?

— mosquito

Por favor, vea la pregunta actualizada, no creo que sea un duplicado :)

— ABcDexter

"Traté de leerlo" , ¿qué pasó?

— Inútil

Se llama así porque hay mucha controversia en torno a ese tema. Vea también esta pregunta de StackOverflow: el caso contra las excepciones comprobadas que menciona algunas citas de personas famosas / influyentes

— Hulk

Respuestas:

Primero te daré un ejemplo (pero al final es la respuesta por qué la controversia).

Supongamos que está editando un documento en un editor de documentos basado en Java y, una vez que haya terminado, elija Archivo-> Guardar como ... y elija guardar el documento en un volumen para el que no tiene permiso de escritura. El Editor no se estrellaría con una fea traza de pila, simplemente le diría que no puede guardar el archivo y le permitirá continuar editando y / o guardar en otra ubicación.

En tal caso, es probable que se esperara una excepción comprobada, atrapada y actuada para recuperarse gentilmente de ella.

Por otro lado, suponga que se trata de una división por cero o una excepción de puntero nulo causada por un error de programación que muestra su cabeza fea solo en ciertas condiciones. Eso podría suceder en cualquier parte del código, la RAM puede estar dañada, etc. Ningún documento de API le diría "este método arrojaría una división por cero si la RAM está dañada" .

Las excepciones marcadas deben ser parte del diseño y los usuarios de esa API deben prepararse para manejarlas. Las excepciones no verificadas pueden ocurrir en casi todas partes y están fuera de nuestro control.

La controversia surge de los programadores que usan excepciones no verificadas (que se extienden desde RuntimeException) cuando deberían usar excepciones marcadas:

como un shorcut para no ser molestado por el compilador
para hacer que sus firmas se vean más simples
porque consideran que las excepciones marcadas son un problema de dependencia (si arroja una nueva excepción marcada en una clase de implementación, debe modificar la firma de la interfaz) y viceversa.

— Tulains Córdova
fuente

"debe modificar la firma de la interfaz", bueno, incluso el compilador lo obliga a hacerlo, y tendrá que manejarlo o declararlo en cada sitio de llamada.

— Hulk

Si una aplicación de IU maneja correctamente un error de una manera fácil de usar se basa en qué tan bien el programador escribió el código. Pueden escribir bien el código de esa manera con excepciones no verificadas, así como alguien más puede manejar los errores de manera incorrecta con excepciones marcadas. La intención de las excepciones marcadas es facilitar a los programadores el manejo adecuado de los errores. La controversia no es lo que has afirmado aquí, sino más bien si realmente logran o no ese objetivo de hacer que el manejo de errores sea más fácil. En opinión de muchos, no lo hacen; Lo hacen más difícil.

— Servy

@Servy ¿De qué manera fácil de usar podría una aplicación de interfaz de usuario manejar el hecho de un chip RAM defectuoso o quedarse sin ciclos de CPU porque otro software no funcionó correctamente?

— Tulains Córdova

@ TulainsCórdova En cualquiera de esos casos, el programa ni siquiera se ejecutará , por lo que no se realiza ningún período de manejo de excepciones , por lo que la forma en que intenta representar un error es irrelevante cuando ni siquiera puede ejecutar ninguno de sus código cuando sucede.

— Servy

@ TulainsCórdova No necesariamente tiene que haber encontrado el error para manejarlo, pero sí, el compilador no le dirá que podría lanzarse. La controversia es si el compilador le dice o no que la excepción podría ser realmente útil. Algunos piensan que sí, otros piensan que no lo es. La pregunta aquí es cuál es la controversia , y esa es la respuesta. Su declaración de cuál es la controversia central de las excepciones marcadas no lo es.

— Servy

-4

No hay controversia en esa página. Es Oracle que le dice a la gente que use excepciones marcadas.

La falsa "controversia" que han inventado aquí es entre los diseñadores de idiomas y los usuarios de idiomas. Los diseñadores permitieron a las personas tirar y atrapar cosas que (en su mente) no deberían ser arrojadas o atrapadas. Entonces crearon una página web quejándose de desarrolladores perezosos.

— ascotan
fuente

No es una controversia incluso si esa página dice poco sobre ella. Lo que es controvertido es la respuesta a la pregunta: "¿Las excepciones marcadas ayudan u obstaculizan el desarrollo de un mejor software?" Y, "Si es así, ¿qué excepciones deben verificarse y cuáles deben desmarcarse?" Apuesto a que podrías comenzar una discusión animada si tienes suficientes desarrolladores (y cerveza) juntos en una sala para responder esas preguntas.

— Solomon Slow