try script nodejs new errores error ejemplo catch and javascript performance exception exception-handling try-catch

nodejs - En Javascript, ¿es costoso usar bloques try-catch incluso si nunca se lanza una excepción?



try catch nodejs (3)

¿Es "lento" utilizar varios bloques try-catch cuando no se lanzan excepciones en ninguno de ellos? Mi pregunta es la misma que esta , pero para Javascript.

Supongamos que tengo 20 funciones que tienen bloques try-catch en ellas. Y otra función que llama a cada una de esas 20 funciones. Ninguno de ellos lanzará una excepción. ¿Mi código se ejecutará más despacio o funcionará mucho peor debido a estos bloques try-catch?


¿Estás haciendo el código de UI de CRUD típico? Usa capturas de prueba, usa bucles que van a 10000 sin ningún motivo en tu código, demonios, usa angulos / brasas - no notarás ningún problema de rendimiento.

Si está haciendo una biblioteca de bajo nivel, simulaciones de física, juegos, etc., entonces el bloque try-catch nunca arrojaría nada de interés, pero el problema es que V8 no lo admitió en su compilador de optimización hasta la versión 6 del motor, por lo que no se optimizará toda la función de contención que contiene sintácticamente una captura de prueba. Sin embargo, puedes evitar esto fácilmente creando una función auxiliar como tryCatch :

function tryCatch(fun) { try { return fun(); } catch(e) { tryCatch.errorObj.e = e; return tryCatch.errorObj; } } tryCatch.errorObj = {e: null}; var result = tryCatch(someFunctionThatCouldThrow); if(result === tryCatch.errorObj) { //The function threw var e = result.e; } else { //result is the returned value }

Después de la versión 6 de V8 (incluida con el Nodo 8.3 y el último Chrome), el rendimiento del código dentro de try-catch es el mismo que el del código normal.


La pregunta original preguntaba sobre el costo de la prueba / captura cuando no se producía un error. Definitivamente hay un impacto cuando se protege un bloque de código con try / catch, pero el impacto de try / catch se desvanecerá rápidamente ya que el código que se protege se vuelve incluso un poco complejo.

Considere esta prueba: http://jsperf.com/try-catch-performance-jls/2

Un simple incremento se ejecuta en 356,800,000 iteraciones por segundo. El mismo incremento dentro de un try / catch es 93,500,000 iteraciones por segundo. Eso está en gastos generales del 75% debido a try / catch. PERO, una llamada de función trivial se ejecuta a 112,200,000 iteraciones por segundo. 2 llamadas a funciones triviales se ejecutan a 61,300,000 iteraciones por segundo.

Una prueba sin ejercicio en esta prueba lleva un poco más de tiempo que una llamada a función trivial. No es una penalización de velocidad lo que importa, excepto en el bucle más interno de algo realmente intenso como una FFT.

El caso que desea evitar es el caso donde realmente se lanza una excepción. Eso es inmensamente más lento, como se muestra en el enlace de arriba.

Editar: Esos números son para Chrome en mi máquina. En Firefox no hay una diferencia significativa entre una prueba no ejercitada y ninguna protección en absoluto. Básicamente, no hay penalidad por usar try / catch si no se lanza ninguna excepción.


Se dice que el bloque try-catch es caro. Sin embargo, si el rendimiento crítico no es un problema, su uso no es necesariamente una preocupación.

La pena OMI es:

  • legibilidad
  • inapropiado en muchos casos
  • ineficaz cuando se trata de la programación asincrónica

Legibilidad : sondear su código con mucho try-catch es desagradable y molesto

inapropiado : es una mala idea insertar dicho bloque si su código no está sujeto a excepción-bloqueo. Insértelo solo si espera una falla en su código. Eche un vistazo al siguiente tema: ¿ Cuándo usar bloques try / catch?

Async : el bloque try-catch es sincrónico y no es efectivo cuando se trata de una programación async . Durante una solicitud de ajax , maneja los eventos de error y de success en las devoluciones de llamada dedicadas. No hay necesidad de try-catch .

Espero que esto ayude,

R.