console.error non è tutto — l'Output Console cattura gli errori che non vedi
L'Output Console di JustZix mostra ciò che una pagina scrive nella console — senza aprire i DevTools. Ma per molto tempo mostrava solo ciò che il codice chiamava esplicitamente tramite console.log. E metà di ciò che vedi nei DevTools non viene affatto da console.log. Dalla versione 2.13.86 questo è cambiato.
console.error non è la stessa cosa di un errore
È facile confondere due cose:
console.error('qualcosa')— il codice registra deliberatamente qualcosa a livello error.throw new Error('qualcosa')— il codice è andato in crash. Nessuno ha chiamatoconsole.error. Eppure i DevTools mostrano una voce rossa con uno stack trace.
Chrome cattura i crash da solo e li mostra nella console. Se l'Output Console avvolge solo console.*, quei crash le sfuggono — e sono spesso le cose più importanti, perché sono ciò che rompe la pagina.
Cosa viene catturato ora
1. Eccezioni non gestite
Un throw non gestito, un errore di sintassi, un errore a runtime — Chrome dispatcha allora un evento error sull'oggetto window. L'Output Console ascolta quell'evento e registra il messaggio insieme allo stack trace e a una posizione file:riga:colonna.
2. Rejection di promise non gestiti
Un someAsync().then(...) senza .catch, o un await che ha lanciato e nessuno l'ha catturato — Chrome dispatcha un evento unhandledrejection. L'Output Console lo ascolta e mostra il motivo del rejection come voce error con il prefisso «Unhandled promise rejection».
Perché la fase di capture
Entrambi i listener sono collegati nella fase di capture. Il motivo: la pagina può avere anche un proprio handler error o unhandledrejection che chiama preventDefault() o stopPropagation(). La fase di capture viene eseguita prima della fase di bubbling, quindi l'Output Console vede l'evento prima che il codice della pagina possa silenziarlo.
Un test di 30 secondi
Apri una JS Console (o una TEMP JS Console tramite Ctrl+Alt+J) e digita:
throw new Error('test boom')
Una voce rossa con uno stack trace dovrebbe apparire nell'Output Console. Ora:
Promise.reject('async boom')
«Unhandled promise rejection: async boom» dovrebbe apparire. Se vedi entrambi — la cattura degli errori funziona.
Cosa ancora NON catturiamo — e perché
- Violazioni CSP. Hanno un evento
securitypolicyviolationseparato — aggiungibile in seguito, fuori ambito per ora. - Errori di rete 4xx/5xx. Un
fetchfallito con un 404 o 500 è una risposta completata con successo — Chrome la mostra nel tab Network, non nella console. La catturiamo solo se il tuo codice lancia da sé dopo aver verificatoresponse.ok. - Avvisi interni di Chrome. I messaggi come «Autofocus processing was blocked» sono generati dal browser stesso — non possono essere intercettati a livello di pagina.
- Fallimenti di caricamento delle risorse. Un
<img>o<script>fallito viene a volte catturato dal listenererrorin fase di capture, ma non sempre — dipende dal tipo di risorsa.
Sono confini deliberati, non lacune. L'Output Console mostra gli errori JavaScript della pagina — ciò che di solito vuoi vedere — non tutto il rumore diagnostico del browser.
Caso d'uso — monitoraggio di produzione senza DevTools
Snappa un'Output Console al bordo della scheda e lasciala. Apri il tuo sito dopo un deploy — se qualcosa va in crash, lo vedi subito, anche se l'errore non viene dal tuo console.error. Per un tester QA è la differenza tra «la pagina sembra OK» e «la pagina sembra OK, ma in background si attiva un TypeError non gestito».
Vedi anche
- Output Console — la descrizione completa della finestra
- TEMP pane — Output Console sotto la scorciatoia Ctrl+Alt+K
- Iniettare su pagine con CSP rigido — come funziona l'hook della console
Installa JustZix — e vedi gli errori della pagina prima dei tuoi utenti.
Valuta questo articolo
Nessuna valutazione — sii il primo.