2013-01-17 10 views
6

Ho riscontrato questo problema quando a una variabile manca un campo e all'utente viene visualizzato l'avviso che questa o quella variabile non ha questa o quella proprietà. Nel caso semplice è molto semplice.Quanti controlli contro null sono appropriati?

if(field) 
    doSomething(field.subField); 

Tuttavia, in situazioni empiriche, mi sono trovato ad arrivare a questo assurdo eccesso di controllo.

if(!data 
    || !data.records 
    || !data.records[0] 
    || !data.records[0].field 
    || !data.records[0].field.id) 
    return null; 
doSomething(data); 

Voglio dire, c'mon - thingy pipe-ish sembra se io sono un idraulico, non è sviluppatore. Quindi, ho la sensazione molto forte che i miei assegni, pur essendo sufficienti, possano essere un po 'eccessivi. C'è una convenzione in JS su quando eseguire un controllo?

+3

Se hai bisogno di farlo costantemente, il tuo codice probabilmente ha più problemi di quanto pensi. – Prinzhorn

+4

C'è una libreria che può aiutare: https://github.com/jclem/steeltoe – epascarello

+2

Come usare un ['try/catch'] (https://developer.mozilla.org/en-US/docs/JavaScript /Reference/Statements/try...catch)? – Blazemonger

risposta

6

Sto per uscire solo con un parere controverso.

In JavaScript, non preoccuparsi di verificare i valori null in luoghi in cui ciò non dovrebbe verificarsi realisticamente. In altre parole, l'idea di controllare ogni proprietà nidificata per null è un po 'eccessiva e serve solo a complicare il tuo script.

Nella mia esperienza, ho imparato a lasciare solo che l'errore di script si verifichi. Ciò è in qualche modo contro-intuitivo per chi scrive codice C o codice di database, in cui un null non gestito può causare l'arresto anomalo del server o dati corrotti, tuttavia nel mondo degli script, è meglio scoprire il proprio errore prima possibile. Se la tua pagina continua a essere caricata senza alcuna indicazione che si sia verificato qualcosa di inaspettato, si manifesterà sotto forma di strani bug più tardi quando l'utente fa clic su un pulsante o invia un modulo.

mio consiglio:

Controllare nullsolo se siete disposti a fare qualcosa al riguardo. Se si dispone di un servizio Web che potrebbe restituire un valore null in caso di problemi, controllarlo e visualizzare un messaggio di errore. Se si ottiene un valore non nullo, si supponga che sia un valore valido e continui. Non c'è motivo di sporcare l'intero script con il controllo nulla che in realtà non porterà alcun beneficio reale al tuo programma.

+0

Il problema sorge quando il cliente è stanco di ricevere messaggi di errore e giudici come una fine del mondo. Ora, ho preso il codice di qualcun altro, quindi dovrò partire con la costante "e c'è di nuovo un errore" -colore sulla mia testa. generalmente, comunque, mi piace il tuo pensiero. Probabilmente mi limiterò a tentare/prendere e riportare solo gli errori, evitando all'utente di essere colpito dai messaggi di errore. Grazie! –

+0

La maggior parte dei browser supporta anche l'evento 'window.onerror', quindi è possibile intercettarlo e accedere tranquillamente. –

+0

Non lo sapevo. Vuoi dire che potrei usare 'window.onerror = function() {...}' ** dentro ** 'window.onload' method ?! O dovrebbe essere collocato sullo stesso livello, parallelamente ad esso? Ed è garantito per catturare tutti gli errori o devo ancora usare * try-catch *? –

2

Normalmente ci si assicurerà che se un oggetto esiste, ha sempre un set di base di proprietà che lo rende utilizzabile.

Ad esempio, se la variabile data ha un valore, si tratta di un oggetto con proprietà records che è sempre un array, anche se vuoto. Se la matrice contiene qualcosa, dovrebbe sempre essere oggetti che ha una proprietà field, che è un oggetto che ha sempre una proprietà id. Ciò ridurrebbe i controlli a:

if (!data || data.records.length == 0) { 
    return null; 
} 
+0

Mi piace l'idea. Tuttavia, come ho commentato di seguito, ho avuto la gioia di riprendere il progetto dopo un programmatore meno esperto e il cliente non è disposto a pagare per una riqualificazione. Ci pagano solo per "riparazione e patching". In retrospettiva, non avrei dovuto accettare il progetto, ma stavo pensando "hey, è solo JS, quanto può essere difficile fare alcune correzioni di bug". Ora sono qui in piedi come un asino ... –

+0

Javascript, nella mia esperienza, è l'ambiente più incline agli approcci folli, al codice pazzesco, alle funzioni di incomprensioni e se ovviamente ... molto difficile da eseguire il debug. – vtortola

+0

Questo approccio causerà errori non rilevati se 'records' non è definito. Se hai davvero bisogno di prendere tutti gli errori usa un 'try/catch'. –