Perché i riferimenti null evitati mentre si generano eccezioni sono considerati ok?

Non capisco del tutto il bashing coerente di riferimenti null da parte di alcune persone del linguaggio di programmazione. Cosa c'è di così brutto in loro? Se richiedo l'accesso in lettura a un file che non esiste, sono perfettamente felice di ottenere un'eccezione o un riferimento null e tuttavia le eccezioni sono considerate buone ma i riferimenti null sono considerati cattivi. Qual è il ragionamento alla base di questo?

I riferimenti null non sono "evitati" più delle eccezioni, almeno da chiunque abbia mai conosciuto o letto. Penso che tu abbia frainteso la saggezza convenzionale.

Ciò che è male è un tentativo di accedere a un riferimento null (o di dereference un puntatore null, ecc.). Questo è male perché indica sempre un bug; non avresti mai fare qualcosa di simile di proposito, e se si sta facendo di proposito, allora questo è ancora peggio, perché è il che rende impossibile distinguere comportamento previsto dal comportamento buggy.

Ci sono alcuni gruppi marginali là fuori che odiano davvero il concetto di nullità per qualche motivo, ma come sottolinea Ed , se non lo hai nullo nildovrai semplicemente sostituirlo con qualcos'altro, che potrebbe portare a qualcosa peggio di un incidente (come la corruzione dei dati).

Molte strutture, infatti, abbracciano entrambi i concetti; ad esempio, in .NET, un modello frequente che vedrai è una coppia di metodi, uno preceduto dalla parola Try(come TryGetValue). Nel Trycaso, il riferimento viene impostato sul valore predefinito (in genere null) e, nell'altro caso, viene generata un'eccezione. Non c'è niente di sbagliato in nessuno dei due approcci; entrambi sono usati frequentemente in ambienti che li supportano.

Dipende davvero tutto dalla semantica. Se nullè un valore di ritorno valido, come nel caso generale della ricerca in una raccolta, quindi restituire null. D'altra parte, se è non è un valore di ritorno valida - per esempio, la ricerca di un record utilizzando una chiave primaria che è venuto dal proprio database - per poi tornare nullsarebbe una cattiva idea, perché il chiamante non sarà aspettava e, probabilmente, non lo controlla.

È davvero molto semplice capire quale semantico usare: ha senso che il risultato di una funzione sia indefinito? In tal caso, è possibile restituire un riferimento null. In caso contrario, genera un'eccezione.

La grande differenza è che se si lascia fuori il codice per gestire i NULL, il codice continuerà molto probabilmente a bloccarsi in un secondo momento con un messaggio di errore non correlato, dove come per le eccezioni, l'eccezione verrebbe sollevata nel punto iniziale di errore (apertura un file per la lettura nel tuo esempio).

Perché i valori null non sono una parte necessaria di un linguaggio di programmazione e sono una fonte coerente di bug. Come dici tu, l'apertura di un file può comportare un errore, che può essere comunicato come valore di ritorno nullo o tramite un'eccezione. Se valori nulli non erano consentiti, esiste un modo coerente e singolare per comunicare l'errore.

Inoltre, questo non è il problema più comune con i null. Molte persone ricordano di verificare la presenza di null dopo aver chiamato una funzione che potrebbe restituirla. Il problema affiora molto di più nella tua progettazione consentendo alle variabili di essere nulle in vari punti dell'esecuzione del tuo programma. Puoi progettare il tuo codice in modo tale che valori null non siano mai consentiti, ma se null non fosse consentito a livello di lingua, nulla di tutto ciò sarebbe necessario.

Tuttavia, in pratica avresti ancora bisogno di un modo per indicare se una variabile è o non è inizializzata. Avresti quindi una forma di bug in cui il tuo programma non si arresta in modo anomalo, ma continua invece a utilizzare un valore predefinito eventualmente non valido. Onestamente non so quale sia la migliore. Per i miei soldi mi piace schiantarmi presto e spesso.

Tony Hoare, che ha creato l'idea di un riferimento nullo in primo luogo, lo chiama il suo errore di un milione di dollari .

Il problema non riguarda i riferimenti null di per sé, ma la mancanza di un adeguato controllo del tipo nella maggior parte dei linguaggi sicuri (altrimenti).

Questa mancanza di supporto, dal linguaggio, significa che i bug "null-bugs" potrebbero essere in agguato nel programma per molto tempo prima di essere rilevati. Tale è la natura dei bug, ovviamente, ma i "null-bug" sono ora noti per essere evitabili.

Questo problema è particolarmente presente in C o C ++ (ad esempio) a causa dell'errore "duro" che provoca (un arresto anomalo del programma, immediato, senza un ripristino elegante).

In altre lingue, c'è sempre la domanda su come gestirli.

In Java o C # si otterrebbe un'eccezione se si tenta di invocare un metodo su un riferimento null e potrebbe andare bene. E quindi la maggior parte dei programmatori Java o C # sono abituati a questo e non capiscono perché uno vorrebbe fare diversamente (e ridere di C ++).

In Haskell, devi fornire esplicitamente un'azione per il caso nullo, e quindi i programmatori Haskell si gongolano con i loro colleghi, perché hanno capito bene (giusto?).

È, in realtà, il vecchio dibattito sul codice di errore / eccezione, ma questa volta con un valore Sentinel al posto del codice di errore.

Come sempre, qualunque sia il più appropriato dipende in realtà dalla situazione e dalla semantica che stai cercando.

Non è possibile allegare un messaggio di errore leggibile dall'uomo a un puntatore null.

(Tuttavia, è possibile lasciare un messaggio di errore in un file di registro.)

In alcune lingue / ambienti che consentono l'aritmetica dei puntatori, se uno degli argomenti puntatore è nullo ed è consentito nel calcolo, il risultato sarebbe un invalido , non nullo puntatore. (*) Più potere per te.

(*) Questo succede molto nella programmazione COM , dove se provi a chiamare un metodo di interfaccia ma il puntatore all'interfaccia è nullo, si tradurrebbe in una chiamata a un indirizzo non valido che è quasi, ma non del tutto, esattamente diverso da zero.

Restituire NULL (o zero numerico o falso booleano) per segnalare un errore è errato sia tecnicamente che concettualmente.

Tecnicamente, stai caricando il programmatore controllando immediatamente il valore di ritorno , nel punto esatto in cui viene restituito. Se si aprono venti file di fila e la segnalazione di errore viene eseguita restituendo NULL, il codice che consuma deve controllare ogni file letto singolarmente ed uscire da eventuali loop e costrutti simili. Questa è una ricetta perfetta per il codice ingombra. Se, tuttavia, si sceglie di segnalare l'errore generando un'eccezione, il codice che consuma può scegliere di gestire immediatamente l'eccezione o lasciarlo salire a tutti i livelli appropriati, anche attraverso le chiamate di funzione. Questo rende il codice molto più pulito.

Concettualmente, se si apre un file e qualcosa va storto, restituire un valore (anche NULL) è sbagliato. Non hai nulla da restituire, perché l'operazione non è terminata. Restituire NULL è l'equivalente concettuale di "Ho letto con successo il file, ed ecco cosa contiene - niente". Se è quello che vuoi esprimere (cioè, se NULL ha senso come risultato effettivo per l'operazione in questione), allora restituisci NULL, ma se vuoi segnalare un errore, usa le eccezioni.

Storicamente, gli errori sono stati segnalati in questo modo perché i linguaggi di programmazione come C non hanno una gestione delle eccezioni incorporata nel linguaggio e il modo consigliato (usando salti lunghi) è un po 'peloso e un po' contro-intuitivo.

C'è anche un lato di manutenzione del problema: con le eccezioni, devi scrivere un codice extra per gestire l'errore; in caso contrario, il programma fallirà presto e con difficoltà (il che è positivo). Se si restituisce NULL per segnalare errori, il comportamento predefinito per il programma è di ignorare l'errore e proseguire, fino a quando non porta ad altri problemi lungo la strada: dati corrotti, segfaults, NullReferenceExceptions, a seconda della lingua. Per segnalare l'errore in anticipo e ad alta voce, devi scrivere un codice aggiuntivo e indovinare cosa: questa è la parte che viene lasciata fuori quando sei in una scadenza stretta.

Come già sottolineato, molte lingue non convertono la dereferenza di un puntatore null in un'eccezione accettabile. Farlo è un trucco relativamente moderno. Quando il problema del puntatore null è stato riconosciuto per la prima volta, le eccezioni non erano ancora state inventate.

Se si consentono puntatori null come caso valido, si tratta di un caso speciale. È necessaria una logica di gestione di casi speciali, spesso in molti luoghi diversi. Questa è una complessità in più.

Che si tratti di puntatori potenzialmente nulli o meno, se non si utilizzano i lanci di eccezione per gestire casi eccezionali, è necessario gestire tali casi eccezionali in altro modo. In genere, ogni chiamata di funzione deve disporre di controlli per quei casi eccezionali, sia per impedire che la chiamata di funzione venga chiamata in modo inappropriato, sia per rilevare il caso di errore alla chiusura della funzione. Questa è una complessità extra che può essere evitata usando le eccezioni.

Più complessità di solito significa più errori.

Le alternative all'utilizzo di puntatori null nelle strutture di dati (ad esempio per contrassegnare l'inizio / la fine di un elenco collegato) includono l'uso di elementi sentinella. Questi possono dare la stessa funzionalità con molta meno complessità. Tuttavia, ci possono essere altri modi per gestire la complessità. Un modo è avvolgere il puntatore potenzialmente nullo in una classe di puntatore intelligente in modo che i controlli null siano necessari solo in una posizione.

Cosa fare del puntatore null quando viene rilevato? Se non è possibile integrare la gestione dei casi eccezionali, è sempre possibile generare un'eccezione e delegare efficacemente la gestione dei casi speciali al chiamante. Ed è esattamente ciò che alcune lingue fanno per impostazione predefinita quando si dereferenzia un puntatore nullo.

Specifico per C ++, ma qui i riferimenti null sono evitati perché la semantica null in C ++ è associata ai tipi di puntatore. È abbastanza ragionevole che una funzione di apertura del file fallisca e restituisca un puntatore nullo; in effetti la fopen()funzione fa esattamente questo.

Dipende dalla lingua.

Ad esempio, Objective-C consente di inviare un messaggio a un oggetto null (zero) senza problemi. Anche una chiamata a zero restituisce zero ed è considerata una caratteristica della lingua.

Personalmente mi piace poiché puoi fare affidamento su quel comportamento ed evitare tutti quei if(obj == null)costrutti nidificati contorti .

Per esempio:

if (myObject != nil && [myObject doSomething])
{
    ...
}

Può essere abbreviato in:

if ([myObject doSomething])
{
    ...
}

In breve, rende il tuo codice più leggibile.

Non do un grido se restituisci un valore nullo o generi un'eccezione, purché tu lo documenti.

Un riferimento Null di solito si verifica perché qualcosa nella logica del programma è stato perso, ovvero: si è arrivati ​​a una riga di codice senza passare attraverso l'impostazione richiesta per quel blocco di codice.

D'altra parte, se si lancia un'eccezione per qualcosa, significa che si è riconosciuto che una particolare situazione potrebbe verificarsi durante il normale funzionamento del programma e che viene gestita.

I riferimenti null sono spesso molto utili: ad esempio, un elemento in un elenco collegato può avere un successore o nessun successore. L'uso nullper "nessun successore" è perfettamente naturale. Oppure, una persona può avere un coniuge o meno - usare nullper "la persona non ha un coniuge" è perfettamente naturale, molto più naturale di avere un valore speciale "senza coniuge" al quale il Person.Spousemembro potrebbe riferirsi.

Ma: molti valori non sono opzionali. In un tipico programma OOP, direi che oltre la metà dei riferimenti non può essere nulldopo l'inizializzazione, altrimenti il ​​programma fallirà. Altrimenti il ​​codice dovrebbe essere pieno di if (x != null)controlli. Quindi perché ogni riferimento dovrebbe essere nullable per impostazione predefinita? Dovrebbe davvero essere il contrario: le variabili dovrebbero essere non annullabili per impostazione predefinita e dovresti esplicitamente dire "oh, e anche questo valore può essere null".

La tua domanda è formulata in modo confuso. Intendi un'eccezione di riferimento null (che in realtà è causata da un tentativo di deriferimento null)? La chiara ragione per non voler quel tipo di eccezione è che non ti dà informazioni su cosa è andato storto, o anche quando - il valore avrebbe potuto essere impostato su null in qualsiasi punto del programma. Scrivi "Se richiedo l'accesso in lettura a un file che non esiste, sono perfettamente felice di ottenere un'eccezione o un riferimento null", ma non dovresti essere perfettamente felice di ottenere qualcosa che non fornisce alcuna indicazione della causa . In nessun punto della stringa "è stato fatto un tentativo di dereference null" si fa menzione della lettura o di file inesistenti. Forse vuoi dire che saresti perfettamente felice di ottenere null come valore di ritorno da una chiamata in lettura - è una questione abbastanza diversa, ma non ti dà ancora informazioni sul perché la lettura non è riuscita; E'