console.error ist nicht alles — die Output Console fängt die Fehler, die du nicht siehst
Die Output Console in JustZix zeigt, was eine Seite in die Konsole schreibt — ohne die DevTools zu öffnen. Aber lange Zeit zeigte sie nur, was der Code explizit per console.log aufrief. Und die Hälfte dessen, was du in den DevTools siehst, kommt gar nicht von console.log. Ab Version 2.13.86 hat sich das geändert.
console.error ist nicht dasselbe wie ein Fehler
Zwei Dinge werden leicht verwechselt:
console.error('etwas')— der Code loggt bewusst etwas auf Error-Ebene.throw new Error('etwas')— der Code ist abgestürzt. Niemand riefconsole.errorauf. Und trotzdem zeigen die DevTools einen roten Eintrag mit Stack-Trace.
Chrome fängt Abstürze selbst ab und zeigt sie in der Konsole. Wenn die Output Console nur console.* umhüllt, rutschen diese Abstürze an ihr vorbei — und sie sind oft das Wichtigste, denn sie sind das, was die Seite kaputtmacht.
Was jetzt erfasst wird
1. Nicht abgefangene Exceptions
Ein nicht abgefangenes throw, ein Syntaxfehler, ein Laufzeitfehler — Chrome dispatcht dann ein error-Event auf dem window-Objekt. Die Output Console lauscht auf dieses Event und protokolliert die Meldung samt Stack-Trace und einer Datei:Zeile:Spalte-Position.
2. Unbehandelte Promise-Rejections
Ein someAsync().then(...) ohne .catch oder ein await, das warf und niemand fing es ab — Chrome dispatcht ein unhandledrejection-Event. Die Output Console lauscht darauf und zeigt den Ablehnungsgrund als Error-Eintrag mit dem Präfix „Unhandled promise rejection".
Warum die Capture-Phase
Beide Listener sind in der Capture-Phase angehängt. Der Grund: Die Seite kann auch einen eigenen error- oder unhandledrejection-Handler haben, der preventDefault() oder stopPropagation() aufruft. Die Capture-Phase läuft vor der Bubbling-Phase, also sieht die Output Console das Event, bevor der Seitencode es stummschalten kann.
Ein 30-Sekunden-Test
Öffne eine JS Console (oder eine TEMP JS Console per Ctrl+Alt+J) und tippe:
throw new Error('test boom')Ein roter Eintrag mit Stack-Trace sollte in der Output Console erscheinen. Jetzt:
Promise.reject('async boom')„Unhandled promise rejection: async boom" sollte erscheinen. Wenn du beides siehst — die Fehlererfassung funktioniert.
Was wir immer noch NICHT fangen — und warum
- CSP-Verstöße. Sie haben ein separates
securitypolicyviolation-Event — später möglich, vorerst außerhalb des Umfangs. - Netzwerk-4xx/5xx-Fehler. Ein fehlgeschlagener
fetchmit 404 oder 500 ist eine erfolgreich abgeschlossene Antwort — Chrome zeigt sie im Network-Tab, nicht in der Konsole. Wir fangen sie nur, wenn dein Code nach der Prüfung vonresponse.okselbst wirft. - Interne Chrome-Warnungen. Meldungen wie „Autofocus processing was blocked" erzeugt der Browser selbst — sie lassen sich nicht von Seitenebene abfangen.
- Fehler beim Laden von Ressourcen. Ein fehlgeschlagenes
<img>oder<script>wird manchmal vom Capture-Phase-error-Listener gefangen, aber nicht immer — es hängt vom Ressourcentyp ab.
Das sind bewusste Grenzen, keine Lücken. Die Output Console zeigt die JavaScript-Fehler der Seite — das, was du normalerweise sehen willst — nicht den gesamten Diagnose-Lärm des Browsers.
Anwendungsfall — Produktionsüberwachung ohne DevTools
Snappe eine Output Console an den Rand des Tabs und lass sie. Du öffnest deine eigene Seite nach einem Deploy — wenn etwas abstürzt, siehst du es sofort, selbst wenn der Fehler nicht aus deinem console.error kommt. Für einen QA-Tester ist das der Unterschied zwischen „die Seite sieht OK aus" und „die Seite sieht OK aus, aber im Hintergrund feuert ein nicht abgefangener TypeError".
Siehe auch
- Output Console — die vollständige Fensterbeschreibung
- TEMP-Panes — Output Console unter dem Shortcut Ctrl+Alt+K
- Injizieren auf CSP-strikten Seiten — wie der Konsolen-Hook funktioniert
Installiere JustZix — und sieh die Fehler der Seite, bevor deine Nutzer sie sehen.
Bewerte diesen Beitrag
Noch keine Bewertungen — sei der Erste.