Decisión para excepciones no verificadas en Scala

17

Como programador de Java, siempre he sido crítico con las Excepciones no verificadas. La mayoría de los programadores lo usan como un camino hacia la facilidad de codificación solo para crear problemas más adelante. Además, los programas (aunque desordenados) con excepciones marcadas son mucho más robustos en comparación con sus homólogos no verificados.

Sorprendentemente en Scala, no hay nada llamado Excepciones marcadas. Todos los Java marcados y desmarcados están desmarcados en Scala.

¿Cuál es la motivación detrás de esta decisión? Para mí, abre una amplia gama de problemas al usar cualquier código externo. Y si por casualidad la documentación es pobre, resulta en KILL.

— Jatin
fuente

11

Como programador de Java, siempre he sido crítico con las excepciones marcadas. El código desordenado nunca es robusto.

— Michael Borgwardt

28

Las excepciones marcadas se consideran principalmente un fracaso. Tenga en cuenta que ningún lenguaje creado después de que Java los adoptó. Ver http://www.artima.com/intv/handcuffs2.html , http://googletesting.blogspot.ru/2009/09/checked-exceptions-i-love-you-but-you.html , http: / /www.mindview.net/Etc/Discussions/CheckedExceptions , etc.

En particular, son incomponibles (excepto volviendo a throws Exception).

En Scala tiene una mejor opción: el uso de tipos algebraicos de los valores de retorno, tales como Option[T], Either[Exception, T], su propio tipo cuando desee el usuario a casos concretos de la manija (por ejemplo, en lugar de

def foo: Int // throws FileNotFoundException, IllegalStateException

tienes

sealed trait FooResult
case class Success(value: Int) extends FooResult
case class FileNotFound(file: File) extends FooResult
case object IllegalState extends FooResult

def foo: FooResult

y ahora se requiere que el consumidor maneje todos los resultados)

Para tratar con código externo que arroja excepciones, tiene scala.util.control.exceptiono scala.util.Try(comenzando con Scala 2.10).

— Alexey Romanov
fuente

44

Nunca entendí que la mayoría de la gente no maneja el argumento de excepciones marcadas . La mayoría de las personas no son buenos desarrolladores. Garantizo que la mayoría de los desarrolladores no van a manejar el resultado del error de todos modos. En realidad, try..catchparece mucho más legible que if. Además, también puedo garantizar que la mayoría de los desarrolladores no escribirán código que devuelva el resultado del error, demasiado complicado en Scala, ni siquiera puede regresar de una función cuando lo desee (como en Pascal)

— Pijusn

55

Encuentro tu comentario confuso y carente de evidencia, @Pius. En Scala, es posible que elegir Opción como tipo de retorno dé como resultado una coincidencia de patrones en lugar de sentencias If . Devolver None en lugar de Some en ese estilo es trivial, no complejo. Los desarrolladores menos perspicaces podrían no elegir escribir funciones que devuelvan tipos algebraicos, pero eso es algo diferente. Finalmente, "ni siquiera puede regresar de una función cuando lo desee", simplemente no es cierto.

— itsbruce

7

Las excepciones marcadas en Java no son tan malas. Por supuesto, los ADT pueden ser una mejor opción para Scala, pero en Java, las excepciones marcadas tienen su lugar y el argumento del código ordenado no tiene ni idea, sin importar cuántos blogs lo repitan. Básicamente dice que felizmente debe ignorar las condiciones severas y posiblemente reparables que pueden ocurrir en su sistema, porque el sistema de tipo tornillo, un código bonito hace que su sistema sea robusto de forma automática. Tal razonamiento también explica por qué tantos codificadores de Java mueven voluntariamente su código a XML (Spring, Maven, etc. ). Sin embargo , extraño la parte bonita aquí.

La razón de la falta de excepciones marcadas en Scala dada por M. Odersky debajo de http://www.scala-lang.org/old/node/8787.html es sorprendentemente diferente y tiene sentido.

El problema con las excepciones marcadas se demuestra mejor con el método de mapa en las listas:

def map[B](f: A => B): List[B]

¿Cómo anotar un mapa con @throws? Si el mapa no obtiene una anotación @throws en sí, entonces presumiblemente no puede pasarle ninguna función que tenga una @throws. Eso introduciría restricciones y distinciones engorrosas para las formas en que se puede usar el mapa. Las cosas serían mejores si pudiéramos afirmar de alguna manera que el mapa arroja todas las excepciones que arroja su argumento de función. Hay algunos sistemas de efectos que pueden expresar esto, pero hasta ahora cada notación que he visto es demasiado pesada.

Lukas Rytz está investigando sobre sistemas de efectos livianos que podrían usarse para expresar el tipo de mapa y otras funciones comunes de manera concisa y precisa. Es una investigación, por lo que actualmente no está claro hasta qué punto tendremos éxito y cuánto de eso se puede poner en Scala. Idealmente, podremos agregarlo en algún momento como un sistema de tipo opcional. Pero es demasiado pronto para hacer predicciones concretas.

Salud

~~No estoy seguro, pero creo que las lambdas de Java 8 también están restringidas a excepciones no marcadas.~~Los métodos en la mayoría de las interfaces funcionales nuevas (¿todas?) En JDK 8 ( java.util.function.*) tampoco declaran excepciones no verificadas.

— woky
fuente

2

Si quieres ganar eficiencia, debes rendirte ... precisión / control <- Necesito una palabra mejor para eso.

Scala se encuentra hacia la cima en lo que respecta a la abstracción. Si uno de los objetivos de Scala es deshacerse del código repetitivo molesto, entonces un lugar obvio para mirar es el manejo de excepciones de Java. Si desea escribir código rápido en java, simplemente continúe lanzando sus excepciones marcadas hasta que lleguen main()y efectivamente no estén marcadas.

No sé si entiendo exactamente lo que estás preguntando, pero esta es la razón más obvia en mi opinión.

Bueno, busqué un poco y alguien ha escrito sobre la tragedia de las excepciones de cheques .

— David Cowden
fuente