Empresas
Empleos
  • Sobre nosotros
  • Soluciones
    • Publicación de vacantes
      Publica tu vacante y recibe candidatos calificados en 48h.
    • Evaluación de candidatos
      500+ pruebas técnicas y psicológicas, más anti-fraude.
    • Headhunting
      Búsqueda ejecutiva a la medida de principio a fin.
    • Nómina + EOR
      Dispersión de nómina y EOR en más de 15 países de LATAM.
  • Precios
  • Empleos

0

184
Vistas
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 Respuestas
Responde la pregunta

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 Denunciar

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 Denunciar
Responde la pregunta
Encuentra empleos remotos

¡Descubre la nueva forma de encontrar empleo!

Top de empleos
Top categorías de empleo
Empresas
Publicar vacante Precios Comercial
Legal
Términos y condiciones Política de privacidad
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomiéndame algunas ofertas
Necesito ayuda