Sentry-javascript: est-il nécessaire de corriger les éléments intégrés dans *chaque* navigateur ?

À tout le moins, il ne s'agit pas entièrement de "nous avons besoin de l'objet d'erreur". Dans certains cas, les erreurs mises à disposition ne sont tout simplement pas utilisables, et cela inclut les navigateurs modernes comme Firefox. Par exemple, ils peuvent ne pas inclure la pile complète ou manquer de détails (comme les numéros de colonne).

Un gros astérisque ici dans la mesure où je ne suis pas sûr que ce soit encore vrai aujourd'hui, mais ce n'était pas si longtemps.

tl;dr quel est le mal à assurer un comportement prévisible, puis à prétendre que les navigateurs ne changent pas/ont des bizarreries

Cela est nécessaire en grande partie pour garantir que la même erreur entraîne exactement les mêmes traces de pile sur différents navigateurs, afin que nous puissions regrouper avec précision plusieurs occurrences du même problème sur différents navigateurs. Cela concerne également la façon dont nous obtenons plus qu'une simple "erreur de script" lorsque des scripts d'origine croisée génèrent des erreurs (voir le billet de blog de Ben à ce sujet ) et nous collectons certains de nos fils d'Ariane automatiques à partir de cette instrumentation.

Tout cela mis à part, le "travail inutile" potentiel que vous décrivez est extrêmement minime, la fonction de détection du comportement window.onerror est difficile à faire proprement, et nous préférons ne pas essayer de garder une matrice à jour de quel navigateur les versions font quoi avec window.onerror alors que nous pouvons simplement normaliser sur tous les navigateurs.

Je dois ajouter que sans try/catch, nous ne pouvons pas générer de "trace synthétique" dans les cas où un objet sans erreur est lancé (par exemple throw "error" ). La trace synthétique vous permet de voir d'où le mauvais objet a été lancé, ce qui peut être crucial dans la recherche de bogues.