Página Inicial>Relacionado com a programação>Código fonte JAVA
Baixar

Manual de erros de JavaScript

Este README contém informações que aprendi ao longo dos anos sobre como lidar com erros de JavaScript, relatá-los ao servidor e navegar por vários bugs que podem tornar tudo isso realmente difícil. Os navegadores melhoraram nessa área, mas ainda há espaço para melhorias para garantir que todos os aplicativos possam lidar de maneira sensata e sólida com qualquer erro que aconteça.

Os casos de teste do conteúdo encontrado neste guia podem ser encontrados em https://mknichel.github.io/javascript-errors/.

Índice

  • Introdução

  • Anatomia de um erro de JavaScript

    • Produzindo um erro de JavaScript

    • Mensagens de erro

    • Formato de rastreamento de pilha

  • Capturando erros de JavaScript

    • janela.onerror

    • tentar/pegar

    • Pontos de entrada protegidos

    • Promessas

    • Trabalhadores da Web

    • Extensões do Chrome

Introdução

Capturar, relatar e corrigir erros é uma parte importante de qualquer aplicativo para garantir a integridade e a estabilidade do aplicativo. Como o código JavaScript também é executado no cliente e em muitos ambientes de navegador diferentes, também pode ser difícil ficar atento aos erros JS do seu aplicativo. Não há especificações formais da web sobre como relatar erros de JS que causam diferenças na implementação de cada navegador. Além disso, houve muitos bugs na implementação de erros de JavaScript nos navegadores que tornaram isso ainda mais difícil. Esta página navega por esses aspectos dos erros JS para que futuros desenvolvedores possam lidar melhor com os erros e esperamos que os navegadores convirjam para soluções padronizadas.

Anatomia de um erro de JavaScript

Um erro de JavaScript é composto de duas partes principais: a mensagem de erro e o rastreamento de pilha . A mensagem de erro é uma string que descreve o que deu errado, e o rastreamento de pilha descreve onde o erro ocorreu no código. Erros JS podem ser produzidos pelo próprio navegador ou lançados pelo código do aplicativo.

Produzindo um erro de JavaScript

Um erro JS pode ser gerado pelo navegador quando um trecho de código não é executado corretamente ou pode ser gerado diretamente pelo código.

Por exemplo:

 var a = 3;a();

Neste exemplo, uma variável que na verdade é um número não pode ser invocada como uma função. O navegador gerará um erro como TypeError: a is not a function with a stack trace que aponta para essa linha de código.

Um desenvolvedor também pode querer lançar um erro em um trecho de código se uma determinada pré-condição não for atendida. Por exemplo

 if (!checkPrecondition()) {
  throw new Error("Não atende à pré-condição!");}

Neste caso, o erro será Error: Doesn't meet precondition! . Este erro também conterá um rastreamento de pilha que aponta para a linha apropriada. Erros gerados pelo navegador e pelo código do aplicativo podem ser tratados da mesma forma.

Existem várias maneiras pelas quais os desenvolvedores podem gerar um erro no JavaScript:

  • throw new Error('Problem description.')

  • throw Error('Problem description.') <- equivalente ao primeiro

  • throw 'Problem description.' <-- ruim

  • throw null <- ainda pior

Lançar uma string ou nulo realmente não é recomendado, pois o navegador não anexará um rastreamento de pilha a esse erro, perdendo o contexto de onde o erro ocorreu no código. É melhor lançar um objeto Error real, que conterá a mensagem de erro, bem como um rastreamento de pilha que aponta para as linhas corretas de código onde o erro ocorreu.

Mensagens de erro

Cada navegador tem seu próprio conjunto de mensagens que usa para as exceções integradas, como o exemplo acima para tentar chamar uma não função. Os navegadores tentarão usar as mesmas mensagens, mas como não há especificações, isso não é garantido. Por exemplo, tanto o Chrome quanto o Firefox usam {0} is not a function para o exemplo acima, enquanto o IE11 reportará Function expected (principalmente sem relatar qual variável tentou ser chamada).

No entanto, os navegadores também tendem a divergir com frequência. Quando houver várias instruções padrão em uma instrução switch , o Chrome lançará "More than one default clause in switch statement" enquanto o Firefox reportará "more than one switch default" . À medida que novos recursos são adicionados à web, essas mensagens de erro precisam ser atualizadas. Essas diferenças podem surgir mais tarde, quando você estiver tentando lidar com erros relatados de código ofuscado.

Você pode encontrar os modelos que os navegadores usam para mensagens de erro em:

  • Raposa de fogo - http://mxr.mozilla.org/mozilla1.9.1/source/js/src/js.msg

  • Chrome - https://code.google.com/p/v8/source/browse/branches/bleeding_edge/src/messages.js

  • Internet Explorer - https://github.com/Microsoft/ChakraCore/blob/4e4d4f00f11b2ded23d1885e85fc26fcc96555da/lib/Parser/rterrors.h

Os navegadores produzirão diferentes mensagens de erro para algumas exceções.

Formato de rastreamento de pilha

O rastreamento de pilha é uma descrição de onde ocorreu o erro no código. É composto por uma série de frames, onde cada frame descreve uma linha específica do código. O quadro superior é o local onde o erro foi lançado, enquanto os quadros subsequentes são a pilha de chamadas de função - ou como o código foi executado para chegar ao ponto onde o erro foi lançado. Como o JavaScript geralmente é concatenado e reduzido, também é importante ter números de coluna para que a instrução exata possa ser localizada quando uma determinada linha tiver uma infinidade de instruções.

Um rastreamento de pilha básico no Chrome se parece com: 

  at throwError (http://mknichel.github.io/javascript-errors/throw-error-basic.html:8:9)
  at http://mknichel.github.io/javascript-errors/throw-error-basic.html:12:3

Cada quadro de pilha consiste em um nome de função (se aplicável e o código não foi executado no escopo global), o script de onde veio e o número da linha e da coluna do código.

Infelizmente, não existe um padrão para o formato de rastreamento de pilha, portanto isso varia de acordo com o navegador.

O rastreamento de pilha do Microsoft Edge e do IE 11 é semelhante ao do Chrome, exceto que lista explicitamente o código global: 

  at throwError (http://mknichel.github.io/javascript-errors/throw-error-basic.html:8:3)
  at Global code (http://mknichel.github.io/javascript-errors/throw-error-basic.html:12:3)

O rastreamento de pilha do Firefox é semelhante a: 

  throwError@http://mknichel.github.io/javascript-errors/throw-error-basic.html:8:9
  @http://mknichel.github.io/javascript-errors/throw-error-basic.html:12:3

O formato do Safari é semelhante ao formato do Firefox, mas também é um pouco diferente: 

  throwError@http://mknichel.github.io/javascript-errors/throw-error-basic.html:8:18
  global code@http://mknichel.github.io/javascript-errors/throw-error-basic.html:12:13

As mesmas informações básicas estão lá, mas o formato é diferente.

Observe também que no exemplo do Safari, além do formato ser diferente do Chrome, os números das colunas são diferentes do Chrome e do Firefox. Os números das colunas também podem divergir mais em diferentes situações de erro - por exemplo, no código (function namedFunction() { throwError(); })(); , o Chrome reportará a coluna para a chamada da função throwError() enquanto o IE11 reportará o número da coluna como o início da string. Essas diferenças voltarão a ocorrer mais tarde, quando o servidor precisar analisar o rastreamento de pilha em busca de erros relatados e desofuscar rastreamentos de pilha ofuscados.

Consulte https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error/Stack para obter mais informações sobre a propriedade stack dos erros. Ao acessar a propriedade Error.stack, o Chrome inclui a mensagem de erro como parte da pilha, mas o Safari 10+ não.

O formato dos rastreamentos de pilha é diferente de acordo com o navegador no formato e nos números das colunas usadas.

Indo mais fundo, há muitas nuances nos formatos de rastreamento de pilha que são discutidas nas seções abaixo.

Nomeando funções anônimas

Por padrão, as funções anônimas não têm nome e aparecem como uma string vazia ou como "Função anônima" nos nomes das funções no rastreamento de pilha (dependendo do navegador). Para melhorar a depuração, você deve adicionar um nome a todas as funções para garantir que elas apareçam no stack frame. A maneira mais fácil de fazer isso é garantir que as funções anônimas sejam especificadas com um nome, mesmo que esse nome não seja usado em nenhum outro lugar. Por exemplo:

 setTimeout(função nomeOfTheAnonymousFunction() { ... }, 0);

Isso fará com que o rastreamento de pilha vá de: 

at http://mknichel.github.io/javascript-errors/javascript-errors.js:125:17

para 

at nameOfTheAnonymousFunction (http://mknichel.github.io/javascript-errors/javascript-errors.js:121:31)

No Safari, isso iria de: 

https://mknichel.github.io/javascript-errors/javascript-errors.js:175:27

para 

nameOfTheAnonymousFunction@https://mknichel.github.io/javascript-errors/javascript-errors.js:171:41

Este método garante que nameOfTheAnonymousFunction apareça no quadro para qualquer código dentro dessa função, tornando a depuração muito mais fácil. Consulte http://www.html5rocks.com/en/tutorials/developertools/async-call-stack/#toc-debugging-tips para obter mais informações.

Atribuindo funções a uma variável

Os navegadores também usarão o nome da variável ou propriedade à qual uma função está atribuída se a função em si não tiver um nome. Por exemplo, em

 var fnNomeVariável = function() { ... };

os navegadores usarão fnVariableName como o nome da função nos rastreamentos de pilha. 

    at throwError (http://mknichel.github.io/javascript-errors/javascript-errors.js:27:9)
    at fnVariableName (http://mknichel.github.io/javascript-errors/javascript-errors.js:169:37)

Ainda mais sutil do que isso, se esta variável for definida dentro de outra função, todos os navegadores usarão apenas o nome da variável como o nome da função no rastreamento de pilha, exceto o Firefox, que usará uma forma diferente que concatena o nome de a função externa com o nome da variável interna. Exemplo:

 função throwErrorFromInnerFunctionAssignedToVariable() {
  var fnNomeVariável = function() { throw new Error("foo"); };
  fnNomeVariável();}

produzirá no Firefox: 

throwErrorFromInnerFunctionAssignedToVariable/fnVariableName@http://mknichel.github.io/javascript-errors/javascript-errors.js:169:37

Em outros navegadores, seria assim: 

at fnVariableName (http://mknichel.github.io/javascript-errors/javascript-errors.js:169:37)

O Firefox usa texto de quadro de pilha diferente para funções definidas em outra função.

Exibir propriedade

O nome de exibição de uma função também pode ser definido pela propriedade displayName em todos os principais navegadores, exceto no IE11. Nestes navegadores, o displayName aparecerá no depurador devtools, mas em todos os navegadores, exceto Safari, ele não será usado em rastreamentos de pilha de erros (o Safari difere dos demais por também usar o displayName no rastreamento de pilha associado a um erro).

 var someFunction = function() {};someFunction.displayName = " # Uma descrição mais longa da função.";

Não há especificações oficiais para a propriedade displayName, mas ela é suportada por todos os principais navegadores. Consulte https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/displayName e http://www.alertdebugging.com/2009/04/29/building-a-better -javascript-profiler-with-webkit/ para obter mais informações sobre displayName.

O IE11 não oferece suporte à propriedade displayName.

O Safari usa a propriedade displayName como o nome do símbolo nos rastreamentos de pilha de erros.

Captura programaticamente de rastreamentos de pilha

Se um erro for relatado sem um rastreamento de pilha (veja mais detalhes sobre quando isso aconteceria abaixo), será possível capturar programaticamente um rastreamento de pilha.

No Chrome, isso é realmente fácil de fazer usando a API Error.captureStackTrace . Consulte https://github.com/v8/v8/wiki/Stack%20Trace%20API para obter mais informações sobre o uso desta API.

Por exemplo:

 função ignoreThisFunctionInStackTrace() {
  var err = novo erro();
  Error.captureStackTrace(err, ignoreThisFunctionInStackTrace);
  retornar err.stack;}

Em outros navegadores, um rastreamento de pilha também pode ser coletado criando um novo erro e acessando a propriedade stack desse objeto:

 var err = new Error('');return err.stack;

No entanto, o IE10 preenche apenas o rastreamento de pilha quando o erro é realmente gerado:

 tentar {
  lançar novo erro ('');} catch (e) {
  retornar e.stack;}

Se nenhuma dessas abordagens funcionar, então é possível criar um rastreamento de pilha aproximado sem números de linha ou colunas, iterando sobre o objeto arguments.callee.caller - isso não funcionará no modo estrito ES5 e não é uma abordagem recomendada.

Rastreamentos de pilha assíncronos

É muito comum que pontos assíncronos sejam inseridos no código JavaScript, como quando o código usa setTimeout ou através do uso de Promises. Esses pontos de entrada assíncronos podem causar problemas para rastreamentos de pilha, pois causam a formação de um novo contexto de execução e o rastreamento de pilha começa do zero novamente.

O Chrome DevTools tem suporte para rastreamentos de pilha assíncronos ou, em outras palavras, garante que o rastreamento de pilha de um erro também mostre os frames que ocorreram antes da introdução do ponto assíncrono. Com o uso de setTimeout, isso irá capturar quem chamou a função setTimeout que eventualmente produziu um erro. Consulte http://www.html5rocks.com/en/tutorials/developertools/async-call-stack/ para obter mais informações.

Um rastreamento de pilha assíncrono será semelhante a: 

  throwError	@	throw-error.js:2
  setTimeout (async)		
  throwErrorAsync	@	throw-error.js:10
  (anonymous function)	@	throw-error-basic.html:14

Os rastreamentos de pilha assíncronos só são suportados no Chrome DevTools no momento, apenas para exceções lançadas quando o DevTools está aberto. Os rastreamentos de pilha acessados ​​a partir de objetos Error no código não terão o rastreamento de pilha assíncrono como parte dele.

É possível fazer polyfill de rastreamentos de pilha assíncronos em alguns casos, mas isso pode causar um impacto significativo no desempenho do seu aplicativo, pois capturar um rastreamento de pilha não é barato.

Somente o Chrome DevTools oferece suporte nativo a rastreamentos de pilha assíncronos.

Nomeando scripts embutidos e avaliação

Os rastreamentos de pilha para código que foi avaliado ou incorporado em uma página HTML usarão o URL da página e os números de linha/coluna para o código executado.

Por exemplo: 

  at throwError (http://mknichel.github.io/javascript-errors/throw-error-basic.html:8:9)
  at http://mknichel.github.io/javascript-errors/throw-error-basic.html:12:3

Se esses scripts realmente vierem de um script que foi incorporado por motivos de otimização, o URL, a linha e os números das colunas estarão errados. Para contornar esse problema, o Chrome e o Firefox suportam a anotação //# sourceURL= (Safari, Edge e IE não). O URL especificado nesta anotação será usado como URL para todos os rastreamentos de pilha, e o número da linha e da coluna será calculado em relação ao início da tag