Empresas
Empregos
  • Sobre nós
  • Soluções
    • Publicação de vagas
      Publique sua vaga e receba candidatos qualificados em 48h.
    • Avaliações de candidatos
      Mais de 500 testes técnicos e psicológicos, mais anti-fraude.
    • Headhunting
      Busca executiva personalizada do início ao fim.
    • Folha de Pagamento + EOR
      Dispersão de folha e EOR em mais de 15 países da LATAM.
  • Preços
  • Empregos

0

189
Visualizações
What is the best practice in production and development for .catch console error?

This is a snippet of my code:

const data = await fetch(url, options)
    .then(res => res.json())
    .then(json => {
      const payID = json.data.id
      sessionStorage.setItem('payID', payID)
      return true
    })
    .catch(err => console.error(`error: ${err}`))

What is your best practice? Do you retain the .catch in development and staging but remove it from PROD? Linter does not want console error in my code.

about 4 years ago · Juan Pablo Isaza
2 Respostas
Responde à pergunta

0

  1. In Development: We use both an error visualizer like error modal + console/error-logger middleware.
  2. In Staging & Production: We use only an error visualizer like modal because you will never expect a user or black-box-tester of the team(in case of testing staging deployment) to go to the console So, what is the use of consoling in production? Note, consoling in production might even be a leakage for hackers to know vividly what is going on. So, I will suggest never to console in staging/production, because anything that gets to staging means it will get to production once finished testing(so production and staging have the same rules).

So about the Eslint thingy, I will suggest you turn it off in the eslint file, and just be conscious of the rule of not putting unnecessary console. For me what I do before committing code for pull-request is to do: SHIFT + CTRL+ F and then type "console.log" to know which files have the console.log method in my VS-CODE and then I remove them.

about 4 years ago · Juan Pablo Isaza Relatório

0

We can't leave a linter decide everything for us, I'd recommend leaving the console.error because most of the cases we need to see these errors in the console and read them, they exist for a reason.

And for the style of writing of course we can use the point free style

.catch(console.error)

And for the linter, it most likely have a rule(at their documentation) to mute that error.

about 4 years ago · Juan Pablo Isaza Relatório
Responde à pergunta
Encontrar trabalhos remotos

Descubra a nova forma de encontrar um emprego!

melhores empregos
Principais categorias de trabalho
Empresas
Postar vaga Preços Comercial
Jurídico
Termos e Condições Política de privacidade
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomende algumas ofertas para mim
Preciso de ajuda