Perché il contenitore Prova catture di vavr Throwable ma non eccezioni?

Question

Perché il contenitore Prova catture di vavr Throwable ma non eccezioni?

voti

0

Io non sono un esperto di sistema di tipo di Java e la gestione delle eccezioni. Ma ho trovato in modo che noi dovremmo prendere solo le eccezioni, ma non di throwable.

Ecco il link: differenza tra l'utilizzo Throwable ed eccezione in un tentativo di cattura

In biblioteca di Vavr ho trovato questo codice sorgente:

public interface Try<T> extends Value<T>, Serializable {
long serialVersionUID = 1L;

static <T> Try<T> of(CheckedFunction0<? extends T> supplier) {
    Objects.requireNonNull(supplier, supplier is null);

    try {
        return new Try.Success(supplier.apply());
    } catch (Throwable var2) {
        return new Try.Failure(var2);
    }
}

Avrei avuto alcun problema in futuro se userò questo contenitore? Will mi mancano alcune eccezioni critiche che possono verificarsi durante l'esecuzione della funzione 'di'?

java exception vavr

È pubblicato 02/12/2019 alle 21:56
fonte dall'utente Alexander Kondaurov

In altre lingue...

3 risposte

Adam Siemion · Answer 1 · 2019-12-02 22:00

voti

2

Throwableè una superclasse di Exception, che significa catch (Throwable var)catture eccezioni pure. Pertanto il codice vavr è corretto - ogni qualvolta vi sia Throwablegettata sarà avvolto in una Try.Failure.

Risposto il 02/12/2019 a 22:00
fonte dall'utente Adam Siemion

Carcigenicate · Answer 2 · 2019-12-02 22:01

Nota ciò che la risposta dice nel post collegato:

Non si dovrebbe in genere fare questo, tranne forse al più alto "catch all" livello di un thread in cui si desidera effettuare il login o altrimenti gestire assolutamente tutto ciò che può andare storto .

L'enfasi è mia.

Questo è probabilmente l'intento qui. Si tratta di un tryinvolucro destinato a gestire tutto e lasciare che l'utente a decidere cosa vogliono fare con e come. Sembra che stanno andando per un costrutto come Scala di Tryfarvi gestire le eccezioni senza di loro cattura manualmente. Per questo a lavorare ed essere coerente, tutto deve essere gestito allo stesso modo, o che avresti avuto alcune eccezioni che hanno bisogno di essere catturati, e altri che sono gestiti da questa classe si propone.

Quanto a

Will mi mancano alcune eccezioni critiche che possono verificarsi durante l'esecuzione della funzione 'di'?

Non li perdere. Stanno essere restituiti avvolto in una Try.Failure, ed è possibile gestire poi dopo aver ricevuto l'errore.

Titulum · Answer 3 · 2020-01-16 17:05

La ragione per cui Throwableè stato utilizzato al posto di Exception, è perché vogliamo che i nostri Tryoggetti anche prendere Errors. Questo suo modo in cui il modello di ereditarietà di Exceptionse Errorsappare come segue:

Se noi prendiamo solo Exceptions, una IOErrorpotrebbe andare in crash il nostro codice e ci impediscono di usare la forza di una Trycatena:

Try.of(() -> throw new IOError(null))
  .onFailure(() -> /* Do something to fix the IOError */);

Quando la cattura Throwable, questa IOErrorsarà catturato, e saremo in grado di eseguire il onFailuremetodo. Se noi unico problema Exception, l'esecuzione sarebbe fermato sulla linea uno, e onFailurenon sarebbe mai stato eseguito.