Fehlerisolierung in JavaScript

Fehler bei der Schnittstellenanforderung, einige Daten in der Schnittstelle fehlen, Betriebsdaten entsprechen nicht den Erwartungen ... Wenn unsere Anwendung veröffentlicht und online ist, beginnen wir, uns diesen Risiken zu stellen.

Sobald diese Probleme zu JavaScript-Fehlern führen (z. B. Nullzeiger-Ausnahmen) und nicht effektiv isoliert werden, können sie Online-Probleme wie weiße Bildschirme auf der Seite und die Unfähigkeit zur Interaktion verursachen.

Während der Vorbereitung für Double 11 haben wir im vergangenen Jahr Front-End-bezogene Online-Probleme gesammelt. Von den 21 gesammelten Fällen stand die Hälfte der Probleme im Zusammenhang mit der Ursache „Datenanomalie löst Anomalie bei der Seitenanzeige aus“. Irgendwie verwandt.

Besonders wichtig ist die Eingrenzung der Auswirkungen von Fehlern innerhalb eines bestimmten Bereichs.

In diesem Artikel sprechen wir über einige der Lösungen, die wir ausprobiert haben, und über die Probleme, auf die wir gestoßen sind.

Beginnend mit einer Nullzeiger-Ausnahme

Das häufigste durch Daten verursachte Problem ist die Nullzeiger-Ausnahme.

　var result = a.b.c.d;

Ein solcher Code ist wie eine Landmine, sobald es sich um dynamische Daten handelt, treten bald Probleme auf.

Kapselt eine Get-Methode, um den Wert abzurufen. Wenn die Daten nicht vorhanden sind, wird undefiniert zurückgegeben, wodurch solche Probleme schnell vermieden werden können.

　var result = get(a, 'b.c.d'); 
　但如同我们期望大家在取值前，都先做判断一样，并不能保证所有人都这么用了，用不用全靠自觉。
if (a && a.b && a.b.c) {
        var result = a.b.c.d;
}

Daher haben wir folgende Lösungen:

Asynchrone Datenüberprüfung

Gedanken zur asynchronen Datenüberprüfung Ja, nach Erhalt Überprüfen Sie die Daten und führen Sie vor der Verwendung eine Schemaüberprüfung durch, um fehlende wichtige Daten und abnormale Typen zu erkennen.

Entsprechend dieser Lösung haben wir die Fetch-Checker-Note-1-Komponente basierend auf Fetch gekapselt.

　fetch-checker zwingt Benutzer, beim Anfordern von Daten das den Daten entsprechende Schema anzugeben:

let schema = {
    "rule": {
      "type": "string",
    },
    "banner": {
      "type": "object",
      "required": true,
      "default": {
        "url": "https://item.taobao.com/item.htm?id=527331762117"
      }
    }
};

Dieses Schema muss beschrieben werden:

Der Typ jedes Feldes

Ob das Feld erforderlich ist

Wenn das erforderliche Feld fehlt, ob es notwendig ist, die Daten zu extrahieren

Der Fetch-Checker ruft die Daten ab. Nach dem Empfang der Daten wird zunächst eine Überprüfungsebene durchgeführt. Bei Bedarf werden die fehlenden Daten ergänzt, bevor sie an den Anrufer zurückgegeben werden. Auf diese Weise müssen die vom Benutzer erhaltenen Daten den Erwartungen entsprechen.

　 Die Herausforderung dieser Lösung besteht jedoch darin:

　 Wie kann sichergestellt werden, dass der Aufrufer eine vollständige Schemabeschreibung bereitstellt? Wenn Sie kein Schema schreiben möchten, können Sie eine grobe Schemabeschreibung bereitstellen, um die Überprüfung zu bestehen.

So optimieren Sie das Schema. Das heißt, es hat keinen großen Einfluss auf die Paketgröße und kann auch die Überprüfungsfunktion erfüllen.

Codekompilierung

Inspiriert von Babel besteht diese Lösung darin, Code mit NPE-Risiken während der Kompilierungsphase in gleichwertigen sicheren Code umzuwandeln. Wie unten gezeigt:

var a = {};
// input
var result = a.b.c;
// output
var result = (_object2 = (_object3 = a) == null ? null : _object3.b) == null ? null : _object2.c;

Wenn a ein leeres Objekt ist, wird beim Ausführen des kompilierten Codes null zurückgegeben, wodurch vermieden wird, dass Code Fehler auslöst und nachfolgende Prozesse blockiert.

Im Babel-Plug-in babel-plugin-safe-member-expression Hinweis 2 haben wir den obigen Versuch unternommen. Derzeit kann diese Funktion im Cake-Projekt selektiv über die Konfiguration „enableSafeMemberExpression“ aktiviert werden.

Diese Lösung hat im Vergleich geringere Zugriffskosten. Entwickler müssen keine Anpassungen am vorhandenen Code vornehmen, aber es gibt immer noch Herausforderungen:

Probleme während der Entwicklungsphase werden nicht leicht aufgedeckt Fehler sollten ohne Rückmeldung gemeldet werden. Der Idealzustand ist: Während der Entwicklungs- und Debugging-Phase so viele Probleme wie möglich aufdecken und Fehler online so weit wie möglich reduzieren.

So definieren Sie versteckte Codes. Derzeit werden alle a.b-Aufrufmethoden nach dem oben genannten Schema kompiliert. Obwohl während des Testvorgangs keine Probleme festgestellt wurden, ist es sicherer, nur mit dem Code umzugehen, der versteckte Gefahren enthält.

Statische Überprüfung

　　以 flow 为代表的静态校验工具，可以在一定程度上检测出 NPE 隐患。
type res = {
        data ?: Object
}
let name = res.data.name;
// property `name`. Propery cannot be accessed on possibly undefined value

Wie im obigen Code beschrieben, müssen Benutzer zunächst klären, ob ihre Daten null sein dürfen Es darf null sein. Durch die Flusserkennung wird ein Fehler erkannt, wenn data.name auf diese Weise aufgerufen wird.

Eine Schwierigkeit besteht jedoch auch darin, allen Unternehmen Zugang zur statischen Verifizierung zu ermöglichen und sicherzustellen, dass Entwickler nach dem Zugriff alle Typen beschreiben.

Das Obige ist der Inhalt der Fehlerisolierung in JavaScript. Weitere verwandte Inhalte finden Sie auf der chinesischen PHP-Website (www.php.cn).