2013-01-17 4 views
6

Ich habe dieses Problem, wenn eine Variable ein Feld fehlt und der Benutzer die Warnung sehen kann, dass diese oder jene Variable diese oder jene Eigenschaft nicht hat. Im einfachen Fall ist es sehr einfach.Wie viele Überprüfungen gegen null sind angemessen?

if(field) 
    doSomething(field.subField); 

In empirischen Situationen habe ich mich jedoch zu dieser absurden Überprüfung gefunden.

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

Ich meine, komm schon - das Rohr-ish-Ding sieht aus wie wenn ich einen Klempner, nicht Entwickler. Ich habe also ein sehr starkes Gefühl, dass meine Schecks, obwohl ausreichend, ein bisschen viel zu übertrieben sein könnten. Gibt es in JS eine Vereinbarung darüber, wann eine Prüfung durchgeführt werden soll?

+3

Wenn Sie dies ständig tun müssen, hat Ihr Code wahrscheinlich mehr Probleme als Sie denken. – Prinzhorn

+4

Es gibt eine Bibliothek, die helfen kann: https://github.com/jclem/steeltoe – epascarello

+2

Wie wäre es mit einem ['try/catch '] (https://developer.mozilla.org/en-US/docs/JavaScript /Reference/Statements/try...catch) statt? – Blazemonger

Antwort

6

Ich werde nur mit einer kontroversen Meinung kommen.

In JavaScript, überprüfen Sie nicht auf null Werte an Orten, wo dies realistisch nicht auftreten sollte. Mit anderen Worten, Ihre Idee, jede verschachtelte Eigenschaft auf Nullen zu prüfen, ist etwas übertrieben und dient nur dazu, Ihr Skript zu komplizieren.

Nach meiner Erfahrung habe ich gelernt, lassen Sie einfach den Skriptfehler auftreten. Dies ist etwas kontraintuitiv für jemanden, der C-Code oder Datenbankcode schreibt, wo ein unbehandelter null den Server zum Absturz bringen oder Daten korrumpieren könnte, jedoch in der Skriptwelt, um besser über Ihren Fehler früher als später zu erfahren. Wenn Ihre Seite weiterhin geladen wird, ohne dass angezeigt wird, dass etwas Unerwartetes passiert ist, wird sie sich später in Form von seltsamen Fehlern manifestieren, wenn der Benutzer auf eine Schaltfläche klickt oder ein Formular absendet.

My Advice:

prüfen nullnur wenn Sie bereit sind, etwas dagegen zu tun. Wenn Sie einen Web-Service haben, der möglicherweise eine null zurückgibt, wenn etwas schief geht, dann prüfen Sie das und zeigen Sie eine Fehlermeldung an. Wenn Sie einen Wert ungleich null erhalten, nehmen Sie an, dass es sich um einen gültigen Wert handelt, und fahren Sie fort. Es gibt keinen Grund, Ihr gesamtes Skript mit einer Null-Überprüfung zu versehen, die Ihrem Programm keinen wirklichen Nutzen bringt.

+0

Das Problem entsteht, wenn der Kunde die Fehlermeldungen satt hat und sich jeder wie ein Ende der Welt beurteilt. Jetzt habe ich den Code von jemand anderem übernommen, also muss ich mit der Konstante "und es gibt wieder einen Fehler" über meinem Kopf verschwinden. Generell mag ich dein Denken. Ich werde wahrscheinlich nur versuchen/fangen und die Fehler nur an mich melden, damit der Benutzer nicht von den Fehlermeldungen gestört wird. Vielen Dank! –

+0

Die meisten Browser unterstützen auch das 'window.onerror'-Ereignis, so dass Sie dies abfangen und ruhig protokollieren können. –

+0

Ich wusste nichts darüber. Du meinst, ich könnte 'window.onerror = function() {...}' ** in ** 'window.onload' Methode ?! Oder sollte es parallel dazu auf der gleichen Ebene platziert werden? Und ist es garantiert alle Fehler zu erfassen oder brauche ich noch * try-catch *? –

2

Normalerweise würden Sie sicherstellen, dass wenn ein Objekt existiert, es immer eine Grundmenge von Eigenschaften hat, die es nutzbar machen.

Zum Beispiel, wenn die Variable data überhaupt einen Wert hat, wäre es ein Objekt mit der Eigenschaft records, die immer ein Array ist, auch wenn es leer ist. Wenn das Array irgendetwas enthält, sollte es immer Objekte mit einer field -Eigenschaft geben, die ein Objekt ist, das immer eine id Eigenschaft hat. Das würde die Schecks reduzieren auf:

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

Ich mag die Idee. Wie ich weiter unten ausführte, hatte ich die Freude, das Projekt nach einem weniger versierten Coder zu übernehmen und der Cusomter ist nicht bereit für eine Sanierung zu bezahlen. Sie zahlen uns nur für "reparieren und patchen". Im Nachhinein hätte ich dem Projekt nicht zustimmen sollen, aber ich dachte "Hey, es ist nur JS, wie schwer kann es sein, einige Bugfixes zu machen". Jetzt stehe ich hier wie ein Esel ... –

+0

Javascript, in meiner Erfahrung, ist die anfälligste Umgebung für verrückte Ansätze, verrückten Code, Features Missverständnisse und wenn natürlich ... sehr schwer zu debuggen. – vtortola

+0

Dieser Ansatz führt zu nicht abgefangenen Fehlern, wenn "records" nicht definiert ist. Wenn Sie wirklich alle Fehler abfangen müssen, versuchen Sie es mit "versuchen/fangen". –