Decisione per le eccezioni non selezionate in Scala

Le eccezioni controllate sono per lo più considerate un errore. Nota che nessuna lingua è stata creata dopo l'adozione da parte di Java. Vedi link , link , collegamento , ecc .

In particolare, sono non utilizzabili (tranne per il ritorno a throws Exception ).

In Scala hai un'opzione migliore: usare tipi algebrici per valori di ritorno come Option[T] , Either[Exception, T] , il tuo tipo quando vuoi che l'utente gestisca casi specifici (ad esempio invece di

def foo: Int // throws FileNotFoundException, IllegalStateException

hai

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

e il consumatore ora è tenuto a gestire tutti i risultati)

Per gestire il codice esterno che genera eccezioni, hai scala.util.control.exception o scala.util.Try (a partire da Scala 2.10).

Eccezioni controllate in Java non è una cosa così brutta. Ovviamente gli ADT possono essere l'opzione migliore per Scala ma in Java, le eccezioni controllate hanno il loro posto e l'argomento codice non ha senso senza tracce, indipendentemente da quanti blog lo abbiano ripetuto. Fondamentalmente dice che dovresti tranquillamente ignorare le condizioni gravi e possibilmente riparabili che possono accadere nel tuo sistema, perché il sistema di tipo a vite, il codice carino rende il tuo sistema robusto automagicamente. Questo ragionamento spiega anche perché così tanti programmatori Java spostano volontariamente il loro codice in XML (Spring, Maven, ecc.). Mi manca comunque la parte pretty qui).

Il motivo della mancanza di eccezioni controllate in Scala dato da M. Odersky sotto il link è sorprendentemente diverso e ha un senso.

The problem with checked exceptions is best demonstrated by the map method on lists:

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

How to annotate map with @throws? If map does not get a @throws annotation itself then presumably you cannot pass it any function that has a @throws. That would introduce cumbersome restrictions and distinctions for the ways in which map can be used. Things would be better if we could state somehow that map throws all exceptions that its function argument throws. There are some effect systems that can express this, but so far every notation I have seen is too heavy.

Lukas Rytz is doing some research on lightweight effect systems that could be used to express the type of map and other common functions in a concise and precise way. It's research, so it's at present unclear to what degree we will succeed and how much of that can be put into Scala. Ideally, we'll be able to add it at some point as an optional type system. But it's much too early to make concrete predictions.

Cheers

Non sono sicuro, ma penso che Java 8 lambda sia limitato alle eccezioni non controllate. I metodi nella maggior parte (tutti?) nuove interfacce funzionali in JDK 8 ( java.util.function.* ) non dichiarano eccezioni non controllate né .

Se vuoi guadagnare efficienza, devi rinunciare .. precisione / controllo < - Ho bisogno di una parola migliore per questo.

Scala si trova verso l'alto per quanto riguarda l'astrazione. Se uno degli obiettivi di Scala si sta sbarazzando del fastidioso codice boilerplate, allora un posto ovvio da considerare è la gestione delle eccezioni di Java. Se vuoi scrivere codice veloce in java, continua a lanciare le eccezioni controllate fino a quando non raggiungono main() e diventano effettivamente deselezionate.

Non so se sto ottenendo esattamente quello che stai chiedendo, ma questa è la ragione più ovvia secondo me.

Bene, ho fatto un po 'di ricerca e qualcuno ha scritto su la tragedia delle eccezioni di controllo .