Sentry-javascript: ist es notwendig, eingebaute Patches in *jedem* Browser zu manipulieren?

Zumindest geht es nicht ausschließlich um "wir brauchen das Fehlerobjekt". Teilweise sind die zur Verfügung gestellten Fehler einfach nicht nutzbar, auch in modernen Browsern wie Firefox. Beispielsweise enthalten sie möglicherweise nicht den vollständigen Stapel oder es fehlen Details (wie Spaltennummern).

Ein großes Sternchen hier, da ich mir nicht sicher bin, ob das heute noch pauschal zutrifft, aber noch nicht so lange her ist.

tl; dr was schadet es, vorhersehbares Verhalten zu gewährleisten und dann so zu tun, als würden sich Browser nicht ändern / Macken haben

Dies ist vor allem notwendig, um sicherzustellen, dass derselbe Fehler in verschiedenen Browsern zu genau denselben Stacktraces führt, sodass wir mehrere Vorkommen desselben Problems in verschiedenen Browsern genau gruppieren können. Dies bezieht sich auch darauf, wie wir mehr als nur „Skriptfehler“ erhalten, wenn ursprungsübergreifende Skripte Fehler werfen (siehe dazu Bens Blogbeitrag ) und wir einige unserer automatischen Breadcrumbs aus dieser Instrumentierung sammeln.

Abgesehen davon ist die potenzielle "unnötige Arbeit", die Sie beschreiben, äußerst gering, die Erkennung des Verhaltens window.onerror durch Funktionen ist schwer sauber durchzuführen, und wir möchten lieber nicht versuchen, eine aktuelle Matrix darüber zu führen, welcher Browser Versionen machen was mit window.onerror , wenn wir stattdessen einfach über alle Browser hinweg normalisieren können.

Ich sollte hinzufügen, dass wir ohne try/catch keinen "synthetischen Trace" in Fällen generieren können, in denen ein Nicht-Fehlerobjekt geworfen wird (z. B. throw "error" ). Die synthetische Spur lässt Sie sehen, woher das fehlerhafte Objekt geworfen wurde, was beim Aufspüren von Fehlern entscheidend sein kann.