È consentito lanciare un'eccezione di runtime da un java.util.Predicate

Question

È consentito lanciare un'eccezione di runtime da un java.util.Predicate

#1 da (2 voti)
#2 da (0 voti)
#3 da (0 voti)

1

L'interfaccia java.util.Predicate contiene il metodo test(...) , di cui JavaDoc indica che [valuta] questo predicato sull'argomento specificato e che [restituisce] true se l'argomento di input corrisponde al predicato, altrimenti falso .

Devo dire che test(..) restituisce sempre true o false e non è mai permesso lanciare un'eccezione? Chiedo, perché le classi dal framework Collections hanno il concetto di "operazioni opzionali", dove è esplicitamente menzionato nel JavaDoc che alcuni metodi potrebbero generare UnsupportedOperationException .

Prima di tutto, non sono un programmatore Java, non lavoro nello sviluppo di software di per sé, ma uso un linguaggio che è simile a Java per alcuni aspetti e cerco di seguire le convenzioni Java ove possibile. Ho provato a cercare risorse sull'argomento, ma la maggior parte di loro menziona come eseguire il controllo delle eccezioni dal codice dello stream.

Proverò a fare un esempio forzato qui. Diciamo che ho una classe Person e una Predicate definita come class IsAdult implements Predicate<Object> . Tieni presente che ho utilizzato Predicate<Object> e non Person . Farebbe bene a lanciare un'eccezione se l'oggetto da testare non è un Person , per il quale è possibile determinare se sono adulti, o se il ritorno del predicato false , visto come l'oggetto che ha testato non poteva in nessun caso sono stato un adulto.

java functional-programming

posta Tudor Timi 03.09.2018 - 13:51

fonte

3 risposte

Leggi altre domande sui tag java functional-programming

Gestione del repository git Creazione di oggetti da una classe / classi con diversi valori fissi che possono essere facilmente espandibili da un utente

score 2 · Answer 1

In questo caso specifico, probabilmente non ha senso gettare un'eccezione nei casi più , perché concettualmente qualunque cosa tu incontri o soddisfa i criteri del predicato o non lo fa.

Se hai previsto casi speciali che non sono né "veri" né "falsi" ma che hanno un altro significato che deve essere gestito in modo diverso, usare una Predicate è la scelta sbagliata, e preferisci invece utilizzare un Function che emette ad es un enum con tre o più valori.

Fondamentalmente il caso principale in cui si vorrebbe lanciare un RuntimeException è quando succede qualcosa che non si aspetta che accada, qualcosa che mostra un problema serio (errore di programmazione, dati corrotti , ecc.) e dove l'unica risposta utile è quella di interrompere qualsiasi cosa stavi facendo ed eseguire un codice di gestione degli errori speciale.

score 0 · Answer 2

Suppongo, dipende. Idealmente, non dovrebbero esserci eccezioni, ma questo non è sempre possibile. Per costruire sul tuo esempio: potresti avere una classe come

class IsKnownToBeAdult implements Predicate<Object> {
    @Overrride
    public boolean test(Object o) {
        return o instanceof Person && ((Person) o).isAdult();
    }
}

ma la maggior parte delle volte non sarà così utile come

/**
  ...
  @throws ClassCastException, if the given object is not a Person.
*/
class IsAdult implements Predicate<Object> {
    @Overrride
    public boolean test(Object o) {
        return ((Person) o).isAdult();
    }
}

Naturalmente, implementare Predicate<Person> è la strada da percorrere, quando possibile.

Un esempio realistico sarebbe un predicato necessario un database di accesso ai file per rispondere. In questo caso, riceverai alcune eccezioni controllate e la tua unica scelta saggia è quella di avvolgerlo in un% di RuntimeException .

Non dovrebbe essere un semplice RuntimeException come troppo aspecifico.
Non dovrebbe essere un UnsupportedOperationException in quanto non si applica (suppongo, non si dovrebbe mai lanciare UOE, tranne nei casi coperti dalla documentazione).
Potrebbe essere un IllegalStateException quando il problema è stato causato da una sessione chiusa o simile.

Nel caso in cui prevedi il problema, suggerirei una classe di eccezione. Altrimenti, fare affidamento sulla gestione generale delle eccezioni non controllate dovrebbe essere fatto. Assicurati,

diffondi correttamente la causa per analisi successive
memorizzi o registri l'eccezione da qualche parte
si presenta all'utente un messaggio chiaro e semplice, quando necessario

score 0 · Answer 3

Alcuni punti:

1) Le eccezioni che fermano il sistema, piuttosto che lasciarlo in uno stato indefinito che potrebbe comprometterne l'integrità, sono una buona cosa. È bene evitare questi, ma mai ok per non permetterli. Sì, anche sui server.

2) Poiché 1) è vero ovunque sarebbe fastidioso documentarlo ovunque.

3) La cura delle eccezioni deselezionate e controllate è una scelta di stile. In alcune codebase un'eccezione non controllata è sempre un segno di un errore del programmatore che dovrebbe essere corretto. Altre codebases odiano le eccezioni controllate dal rumore lasciano sulle firme dei metodi e evitano con gioia di permetterle. Invece usano sempre eccezioni non controllate. Conformarsi al codice base.

4) A causa di 3) nessuno qui sa davvero quanto seriamente prendere la firma dei metodi. Dovremmo esaminare la tua base di codice.