Perché Java getSystemResourceAsStream consuma in silenzio IOExceptions?

3

Durante il tentativo di eseguire il debug di un problema strano in cui sapevo che un'eccezione avrebbe dovuto essere generata ma non lo era, ho trovato quanto segue nella classe java.lang.ClassLoader della libreria standard Java:

/**
 * Open for reading, a resource of the specified name from the search path
 * used to load classes.  This method locates the resource through the
 * system class loader (see {@link #getSystemClassLoader()}).
 *
 * @param  name
 *         The resource name
 *
 * @return  An input stream for reading the resource, or <tt>null</tt>
 *          if the resource could not be found
 *
 * @since  1.1
 */
public static InputStream getSystemResourceAsStream(String name) {
    URL url = getSystemResource(name);
    try {
        return url != null ? url.openStream() : null;
    } catch (IOException e) {
        return null;
    }
}

Quale motivo ci sarebbe dove è stata presa la decisione che questa eccezione non dovrebbe essere lanciata ma invece consumata silenziosamente?

Pur discutendo di questo con un collega una possibile opzione era che forse questa funzione precedesse IOException e quindi questo fu aggiunto per mantenere la retrocompatibilità, tuttavia questo metodo fu aggiunto in Java 1.1, mentre IOException fu aggiunto in 1.0.

Questa è un'operazione di file quindi IOExceptions non sarebbe fuori luogo, quindi perché i produttori di una lingua basata su eccezioni scelgono di restituire null superando un'eccezione generata?

    
posta Ellie Harper 23.05.2017 - 21:04
fonte

2 risposte

2

Gli autori della funzione definiscono ciò che "non può essere trovato" include. Qui includono qualsiasi IOException s lanciata nel tentativo come "impossibile trovare". Questo semplifica l'utilizzo di questa funzione, in quanto l'utente deve solo verificare la presenza di null. Una libreria più moderna potrebbe avere questo ritorno Option<InputStream> .

Notate come non tentano di catturare getSystemResource , la documentazione di ciò specifica anche che restituisce null in caso di fallimento.

    
risposta data 24.05.2017 - 10:26
fonte
4

È improbabile che fallisca perché:

getSystemResource () e quindi getSystemResourceAsStream () stanno utilizzando il caricatore di classe System.

Legge dal disco locale.

Se fallisce, non è stato possibile leggere un file jar o dir tree dal classpath.

Errori di IO sono improbabili, dato che abbiamo già iniziato a correre da questi vasi, che sono stati verificati (e già letti).

Il mancato rilevamento del file ha generalmente un nome file errato o una brutta build del codice che non include la risorsa. In questi casi un puntatore nullo renderà il tuo codice in crash rapidamente durante i test e il tuo codice di produzione non avrà bisogno di gestire un IOException che si verifica solo se la tua build è rovinata.

    
risposta data 24.05.2017 - 08:37
fonte

Leggi altre domande sui tag