Richiede la gestione di riferimento Null esplicita

Question

Richiede la gestione di riferimento Null esplicita

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

5

Uno dei problemi che ho con riferimenti null è che potrebbero non essere eccezionali. Nella mia attuale posizione, ci sono pochi requisiti e sei fortunato se vengono seguite le convenzioni. Ciò significa che non essere in grado di gestire una richiesta è un evento frequente e il lancio di un'eccezione è troppo lento (si pensi a milioni di richieste). Sono incaricato di scrivere un'API per gestire queste richieste e sto cercando di decidere come gestire gli errori.

Il nostro codice è scritto in C # e sono un grande fan di LINQ. So che LINQ gestisce questo problema fornendo due metodi "Function ()" e "FunctionOrDefault ()". Restituendo il valore predefinito (di solito nullo), rendiamo molto facile allo sviluppatore spararsi al piede. D'altra parte, lanciare un'eccezione è inaccettabile per noi. C'è anche il pattern "TryParse", ma che non si presta bene alle espressioni lambda.

Recentemente ho scoperto il tipo di opzione in F # e come richiede la gestione esplicita di entrambi i casi Some e None o il tuo assembly non verrà compilato. Questa sembra una soluzione molto migliore per il problema del valore nullo piuttosto che lasciare allo sviluppatore il compito di ricordare di implementare la gestione degli errori.

Potrei implementare un tipo di opzione che non compilerà entrambi e restituirà il valore desiderato a meno che non vengano gestiti entrambi i casi Some e None. Il contratto per la mia implementazione sarebbe simile a questo:

Option<SomeClass> option = new SomeClass { Value = 5 }.ToOption(); // Extension method
int value = option.Some(x => x.Value).None(x => x.Default(25)); // Other helper methods provided as well for None cases.

Quindi la mia domanda è, se ho la possibilità di richiedere una gestione di riferimento null esplicita, ci sono degli svantaggi di questo approccio? Sarebbe meglio attenersi alle convenzioni piuttosto che cercare di risolvere questo problema in anticipo per prevenire futuri bug nascosti?

c# api null

posta mortalapeman 23.03.2013 - 05:37

fonte

2 risposte

3

By returning the default value (usually null), we make it very easy for the developer to shoot himself in the foot.

Non sono d'accordo, e credo che tu sia sulla strada dell'ingegneria eccessiva. Se hai una funzione che restituisce null e l'utente di quella funzione lo gestisce correttamente, tutto va bene. Se l'utente non lo fa (il che significa che tenta di utilizzare l'oggetto restituito), otterrà un'eccezione, quindi nessun errore verrà mascherato .

L'unico problema qui è che l'utente potrebbe non ricevere un messaggio di errore chiaro. Ma questo sarebbe anche il caso quando usi qualsiasi altro tipo di meccanismo di segnalazione degli errori e l'utente delle tue funzioni dimentica di "tradurre" i messaggi tecnici di errore in messaggi di testo libero che mostrano la causa principale di un problema.

Meglio investire il tempo per insegnare ai compagni di squadra a scrivere test per rivelare la gestione degli errori mancanti.

risposta data 23.03.2013 - 11:51

fonte

Leggi altre domande sui tag c# api null

Sviluppo basato su test durante l'implementazione di un elenco di lunghezza flessibile Database di documenti NoSQL come coda di messaggi

score 4 · Accepted Answer

Non ne hai bisogno. Ecco il mio ragionamento:

Potresti sottovalutare gli utenti della tua API. Ogni libro di testo che abbia mai letto sui linguaggi di programmazione conteneva una sezione su come verificare i valori nulli. Molte lingue includono funzionalità di coalescenza nulla o controllo nullo + zucchero sintattico.
Devi dimostrare a me (un altro programmatore) perché hai bisogno di questa convenzione .
Se non è possibile dimostrare che fornisce un flusso di lavoro significativo o un vantaggio di debug, è necessario utilizzare un approccio più semplice. Soprattutto se l'approccio più semplice è già insegnato dalla comunità in generale.
```
var value = proxy.FirstOrDefault();
if (value != null) { ...
```
Considera la significatività degli idiomi che crei. Il codice sopra è più o meno significativo del tuo metodo ToOption() ? Se sono più o meno uguali, non farlo. Solo lavori che offrono un vantaggio significativo. Questa è l'idea alla base di YAGNI.
Considera un dibattito simile nella community nodejs sull'utilità dell'applicazione del modello Promise / A per le biblioteche. Anche se non è equivalente, puoi notare che c'è qualche discontinuità sul problema.
Infine, vorrei sbagliare sul fatto di consentire ai consumatori di scegliere il livello di complessità che desiderano. Se il tuo approccio ToOption è chiaramente superiore, i consumatori lo implementeranno comunque.