Quando dichiarare @throws con un'annotazione Scala - genitore astratto o implementazione concreta?

Question

Quando dichiarare @throws con un'annotazione Scala - genitore astratto o implementazione concreta?

#1 da (4 voti)

6

In questa domanda StackOverflow ho chiesto del comportamento dell'annotazione @throws in Scala. Ora che capisco come funziona, voglio chiedere delle migliori pratiche con l'utilizzo. Ecco un repost del mio codice da quella domanda:

abstract class SFoo {
    def bar(): Unit
}

class SFoobar extends SFoo {
    @throws[Exception]
    override def bar(): Unit = {
        throw new Exception("hi there")
    }
}

Il problema qui è che se dichiaro una variabile come SFoo in Java, ma la istanziamo come SFoobar , il compilatore Java non è in grado di rilevare l'eccezione verificata e si verificherà un'eccezione di runtime. Quindi la mia inclinazione sarebbe dichiarare @throws nella classe genitrice, SFoo .

Ma dì che ho un'altra implementazione concreta di SFoo :

class SBarfoo extends SFoo {
    override def bar(): Unit = {
        println("no exception here!")
    }
}

In questo caso, è appropriato dichiarare @throws nella classe genitore se una delle sue implementazioni non genera un'eccezione? Qual è la migliore pratica qui? (Ci scusiamo per la domanda soggettiva.)

java documentation object-oriented-design exceptions scala

posta 2rs2ts 05.08.2014 - 19:21

fonte

1 risposta

Leggi altre domande sui tag java documentation object-oriented-design exceptions scala

Controllo delle versioni e distribuzione dei sistemi dipendenti Dove memorizzare le proprietà aziendali globali?

score 4 · Accepted Answer

Non è necessario lanciare l'eccezione ogni volta affinché il contratto @throws sia soddisfatto. In effetti, nella stragrande maggioranza del tempo, non lo farai. Non c'è niente di sbagliato nell'avere un'implementazione che non genera mai un'eccezione, se veramente appartiene a una sottoclasse. Posso pensare a molte applicazioni in cui ciò avrebbe senso. Ad esempio, un'implementazione potrebbe utilizzare una cache del disco, in cui un'altra potrebbe utilizzare una cache di memoria.

Detto questo, Scala ha intenzionalmente omesso le eccezioni controllate per una buona ragione: violano il principio aperto / chiuso perché non puoi lanciare una nuova eccezione in una sottoclasse senza propagarla attorno a tutte le classi esistenti nella gerarchia, come così come i metodi che chiamano questi metodi. Le eccezioni controllate sono state omesse da C # e altri linguaggi recenti in gran parte a causa di come le eccezioni verificate problematiche si sono rivelate nelle applicazioni Java reali. Scala ha solo controllato le eccezioni per la compatibilità con il codice Java. Se non chiamerai il codice Scala da codice Java, non dovresti usarli.