Null in ogni tipo e controllate le eccezioni in Java?

4

So che l'aggiunta di null a ogni tipo in Java è fonte di molta frustrazione per quanto riguarda il sistema dei tipi della lingua. Allo stesso tempo, in genere ascolto lamentele sulle eccezioni controllate - che ingombrano le interfacce, incoraggiano l'ingerenza delle eccezioni, ecc. Mi sembra come se l'abitare nullo di ogni tipo sia un modo per aggirare il linguaggio - come voglio che il tipo di questo sia X , ma in realtà è X or null ; semplicemente non sembra così ed è facile da dimenticare. Le eccezioni non spuntate forniscono un modo per il tipo di qualcosa di essere X or throws Exception invece di apparire solo X ? Fornisce un metodo in-code per specificare come può fallire qualcosa.

I null in ogni tipo e le eccezioni non controllate sembrano come concetti duali, ma uno è disprezzato e l'altro elogiato. Perché è così?

    
posta oconnor0 13.01.2012 - 23:41
fonte

2 risposte

2

La maggior parte delle persone che disprezzano i NULL non hanno mai scritto in una lingua senza di loro. Le persone che disprezzano le eccezioni controllate hanno scritto in una lingua con loro. Le persone hanno visto gli svantaggi delle eccezioni controllate molto più degli svantaggi della programmazione NULL-less. Le lingue più diffuse hanno utilizzato eccezioni controllate, ma nessun linguaggio popolare ha eliminato NULL.

Entrambe queste idee stanno cercando di dimostrare una certa correttezza di nozioni in un programma. A mio avviso, sembra una buona idea in teoria, ma tende a cadere a pezzi nella pratica. Lo sforzo e le restrizioni imposte ai tentativi di dimostrare la correttezza non valgono generalmente i benefici della limitata quantità di correttezza dimostrata.

Esistono molte critiche specifiche alle eccezioni controllate. Non ho intenzione di ripeterli tutti qui, sono sicuro che è stato fatto a morte. NULL potrebbe non mostrare gli stessi problemi. Tuttavia, la mancanza di una programmazione NULL-less diffusa potrebbe significare che semplicemente non abbiamo avuto il tempo di vederli. O forse le eccezioni controllate producono semplicemente più problemi, quindi la programmazione senza NULL.

    
risposta data 14.01.2012 - 00:03
fonte
1

Non chiamerei null e ho controllato i concetti doppi delle eccezioni; in effetti, sono la stessa cosa in incognito (più su questo più tardi). L'errore di segnalazione in un valore di ritorno e le eccezioni non selezionate sono concetti duali. Il ritorno di null è one way per segnalare un errore nel valore di ritorno, ma sovverte il sistema di tipi della lingua. Ti sei già accorto di questo fatto: non puoi mai avere il tipo di solo stringhe, devi vivere con il tipo di stringhe e% di% equazione.

L'approccio corretto all'uso del valore restituito è quello di eliminare null e utilizzare un tipo separato (solitamente chiamato null o Option ) che rappresenta il concetto di "un valore di tipo Maybe , o %codice%". Un T non è un Nothing - non puoi assegnarne uno all'altro e devi ispezionare esplicitamente Option X e gestire entrambi i casi. Non puoi semplicemente dimenticare che la funzione potrebbe non riuscire a restituire un valore.

X funziona bene quando i guasti sono comuni e possono essere gestiti immediatamente. Non funziona così bene quando i guasti sono rari e il chiamante immediato non può fare nulla di significativo a riguardo. Quando il fallimento può essere gestito solo più in alto nello stack, devi restituire Option fino in fondo - se ottieni un valore, procedi, e se non lo fai, restituisci Maybe , più e più volte finché non ottieni al punto in cui è effettivamente possibile gestire l'errore. Immagina se la divisione non lanciasse un'eccezione e invece restituisse Maybe - che dolore!

Non solo è maldestro, obbliga tutto il gestore e l'errore a conoscere la possibilità di un errore e modifica il suo tipo di ritorno a Nothing . Questo ostacola il modo in cui si scrivono funzioni che assumono altre funzioni come argomenti. A volte vuoi passare una funzione che potrebbe teoricamente fallire, ma hai assicurato che non sarà così, o se non lo faresti, non potrai farci nulla. Le eccezioni non controllate vengono qui in soccorso, perché eseguono automaticamente l'inoltro dell'errore e qualsiasi cosa nel mezzo può ignorare beatamente la possibilità di un errore. Se la tua unica opzione fosse Maybe Double e controllasse le eccezioni, saresti sfortunato, perché la possibilità di errore è codificata nel tipo di reso della funzione e ciò lo rende incompatibile con il tipo di funzione che ti aspetti.

Il problema con le eccezioni controllate è che non sono adatti per nessuno dei due scopi. Quando l'errore deve essere gestito ulteriormente, si forza tutto il codice tra il gestore e l'errore per riflettere la possibilità di errore nella sua firma. Quando l'errore può essere gestito immediatamente, ottieni tutti i benefici di Maybe - non puoi dimenticarti di gestirlo - ma è più semplice da usare rispetto a un semplice if / switch! Quindi è un po 'goffo Maybe nei vestiti delle eccezioni.

    
risposta data 29.01.2014 - 21:10
fonte

Leggi altre domande sui tag