Sentry-javascript: Alle ausgelösten Fehler automatisch protokollieren?

haha, die Fehlerbehandlung in Javascript ist wirklich schrecklich. Können Sie mir ein Beispiel geben, wie Sie die Fehler werfen?

Wenn wir beispielsweise eine Zeichenfolge werfen, können wir keine Informationen außer der gesendeten Nachricht erhalten. Mit einem tatsächlichen Error -Objekt können wir versuchen, einen Stack zu erhalten.

Also je mehr Informationen, desto besser dafür.

In der Tat.

Ich werfe einen Fehler wie folgt:

throw new Error("Error");

Manchmal loggt es sich in den Wachposten ein und manchmal nicht.

Ist das auf einer Seite, die ich mir irgendwo anschauen kann? Oder kann man es irgendwo hinstellen? Ehrlich gesagt, das ist einfach nicht genug Informationen. Es gibt ungefähr 10 Faktoren, die dazu beitragen können, warum ein Fehler nicht protokolliert wird, und die meisten davon liegen nicht in unserer Hand. :) Wenn ich also den vollständigen Kontext sehen kann, kann ich Ihnen einen Vorschlag machen, um dem Browser zu helfen.

Die App ist eigentlich in CoffeeScript geschrieben, das mit require.js in JavaScript kompiliert wird. Der Haupteinstiegspunkt sieht so aus:

Raven.config('http://[email protected]');
Raven.context(function() {
  define(['cs!csmain']);
});

Ich habe es auch ohne den Wrapper context versucht und das schien nichts zu ändern. Es protokollierte immer noch throw -Aufrufe, die weiter oben in der Aufrufliste getätigt wurden, während die darunter liegenden ignoriert wurden.

Führen Sie Raven.install() aus

Und für require.js würden Sie Folgendes tun, wenn Sie Module explizit umschließen möchten:

define(['module'], Raven.wrap(function(module) {
  // insert cool stuff here
}));

Ich habe es im Snippet vergessen, aber ich rufe install() nach config() an

Ich habe nicht versucht, Module zu umschließen, aber ich dachte mir, wenn es an einigen Stellen bereits funktioniert, warum nicht an anderen?

Es hängt alles wirklich vom Callstack ab. Wenn die Dinge anfangen, in asynchrones Land zu geraten, wird es schwierig. Dies würde beispielsweise nicht wie erwartet funktionieren:

Raven.context(function() {
  setTimeout(function() {
    throw new Error('crap');
  }, 1);
});

Die interne Funktion wird in ihrem eigenen Kontext außerhalb des Hauptkontexts ausgeführt. Node.js löst dies mit einer Sache namens „Domains“, aber leider existieren diese im Browserland nicht.

Wenn also ein Fehler nicht erkannt wird und bis ganz nach oben sprudelt, wird er normalerweise abgelehnt, weil er zu diesem Zeitpunkt zu 100 % wertlos ist.

Ah ich sehe. Vielleicht gibt es eine Möglichkeit, window.onerror zu verwenden?

FWIW, wenn möglich, ist die zuverlässigste Methode zum Erfassen einer Ausnahme die explizite Verwendung Raven.captureException . Ich verstehe, dass das nicht immer machbar ist, aber nur ein FYI.

Also ein expliziter Versuch ... außer Block ist am zuverlässigsten:

try {
  throw new Error('something');
} catch(e) {
  Raven.captureException(e);
}

Rechts. Natürlich wäre es großartig, Fehler automatisch zu erfassen, aber JavaScript macht es nicht zu einem einfachen Spiel ...

@heuter nein. :) Und das ist der lustige Teil. Sobald ein Fehler zu window.onerror gelangt, ist es kein tatsächliches Error -Objekt mehr. Es wird zu einer nutzlosen Saite abgeflacht. Und es führt auch zu domänenübergreifenden Sicherheitsproblemen. Wenn also ein Fehler window.onerror trifft, wird er normalerweise verworfen, da die einzigen Informationen, die wir haben, möglicherweise nur sind: "Script error." .

Saugt. Oh, ich danke dir für die Klarstellung!

Nein, Javascript nicht. Es ist wirklich schrecklich. :) Ich recherchiere und erkunde aktiv Möglichkeiten, den Browser auszunutzen, um uns bessere Informationen zu liefern. Mir ist sogar die Idee gekommen, Monkey Patch Function.prototype.call zu machen. Aber das sind wahrscheinlich wirklich schlechte Nachrichten.

Total! Wenn Sie Empfehlungen oder Vorschläge zur Klärung der Dokumentation haben, lassen Sie es mich bitte wissen. Ich suche immer nach dem Zeug.

Wird es tun, die Konfigurations- und Nutzungsdokumente waren ziemlich einfach und leicht zu befolgen.

Ich frage mich, ob es eine Möglichkeit gibt, Error zu erweitern, damit dies funktioniert.

@mattrobenolt , das ist der Ansatz, den wir mit CoffeeScript verfolgen.

window.Error = class extends Error
  constructor: ->
    error = super
    Raven.captureException error
    return error

Dann verwenden Sie einfach throw new Error "Test Error"

Aktualisierter Kommentar oben zur Klarstellung.

Hmm. Ich werde am Wochenende damit spielen. Das letzte Mal, als ich es versuchte, ließ es mich nicht über das Fenster flicken. Fehler. Ich werde es noch einmal in weiteren Browsern versuchen und sehen, was möglich ist.

Danke für die Warnung!

Können Sie mir das auch in normalem Javascript geben? Ich bin mir ziemlich sicher, was es tut, ich möchte es nur noch einmal überprüfen. Ich schreibe kein Coffeescript.

Bitte schön:

var __hasProp = {}.hasOwnProperty,
  __extends = function(child, parent) { for (var key in parent) { if (__hasProp.call(parent, key)) child[key] = parent[key]; } function ctor() { this.constructor = child; } ctor.prototype = parent.prototype; child.prototype = new ctor(); child.__super__ = parent.prototype; return child; };

window.Error = (function(_super) {

  __extends(_Class, _super);

  function _Class() {
    var error;
    error = _Class.__super__.constructor.apply(this, arguments);
    Raven.captureException(error);
    return error;
  }

  return _Class;

})(Error);

Jetzt, wo ich darüber nachdenke, ist dies ein fehlerhafter Ansatz. Das einfache Überschreiben des Konstruktors wird dazu führen, dass Raven jedes Fehlerobjekt erfasst, unabhängig davon, ob es geworfen wird oder nicht. :)

FYI, errorception hat einen Weg gefunden, damit umzugehen. Wäre cool, wenn raven-js das auch machen könnte.

@dmcquay Können Sie ein Beispiel geben, das Errorception erfasst? Ich kann es wahrscheinlich zurückentwickeln.

Ich gehe eigentlich davon aus, dass alle JS-Error-Handler zu 50% aus raven.js bestehen ;)

:Kacke:

@BYK , irgendwelche Ideen?

Ich habe kein Insiderwissen über Errorception. Ich verwende den Dienst und er scheint wie angekündigt zu funktionieren. Das ist alles was ich weiß.

Ich habe untersucht, wie sie funktionieren, und es sieht so aus, als würden sie sich einfach an window.onerror anhängen und sich nicht um den Stack-Trace kümmern. Zumindest für solche Sachen.

Das Hijacking des Error-Objekts funktioniert für Firefox, aber der Punkt von @mattrobenolt , alle zu erfassen, auch diejenigen, die nicht geworfen werden, ist ein berechtigtes Anliegen.

Eine unsaubere Problemumgehung könnte darin bestehen, erstellte Error -Instanzen zu speichern, indem Sie den globalen Konstruktor übernehmen und auch auf onerror hören und message , fileName und lineNo vergleichen.

Bei der Auswertung aller Fehlerbenachrichtigungsdienste ist mir aufgefallen, dass einige Javascript-spezifische Dienste (z. B. https://qbaka.com/) den Stack-Trace verfolgen und die Benutzeraktion anzeigen, die zu einem bestimmten Fehler geführt hat. Schade, dass errorception das nicht tut, da es in jeder anderen Hinsicht überlegen zu sein scheint.

Wir werden Sentry für unseren Django-Code verwenden, und ich bin auf dieses Problem gestoßen, als ich nach Informationen darüber gesucht habe, wie Sentry für Javascript funktioniert. Erfordert die aktuelle Implementierung von raven-js, dass der Code explizit alle JS-Fehler abfängt und sie an Sentry meldet?

@adityar7 Tut es nicht. Raven.js versucht sein Bestes, um Dinge zu patchen und abzufangen, wenn es möglich ist. In einigen Randfällen müssen Sie möglicherweise explizit umbrechen, aber wir bemühen uns sehr, die Dinge automatisch zu erledigen.

@mattrobenolt Habe es zum Laufen gebracht, indem ich einige Syntax korrigiert habe. Danke!