Prueba ... ¿Los bloques de captura siempre son caros?

Question

Duplicar posibles:
Do try/catch blocks hurt performance when exceptions are not thrown?

Hola a todos, Sólo una pregunta rápida sobre try..catch bloques. He oído que son caros de usar y no deben usarse como parte del flujo de un programa. Sin embargo, para validar las direcciones de correo electrónico, estoy usando el siguiente código.

 try 
     { 
      MailAddress checkEmail = new MailAddress(testEmail); 

      return true; 
     } 
     catch 
     { 
      return false; 
     } 

Debido a la validación previa, no tengo que capturar muchas excepciones a menos que sea un intento de eludir la validación. Mi pregunta es, ¿lo intentan? Los bloques de captura solo son caros si se detecta una excepción, o ¿es siempre caro independientemente de si se produce alguna excepción?

Gracias

EDIT: Gracias por todas las respuestas. He decidido que, dado que la verificación (en C#) no es muy costosa, me quedaré con este método. Se debe principalmente a que se produce una excepción real, ya que existen pasos de validación previos que aseguran que nadie ingrese accidentalmente una dirección de correo electrónico no válida.

Answer 1

En general, , en la actualidad de implementaciones, ingresar un bloque try no es costoso en absoluto (esto no siempre fue cierto). Sin embargo, lanzar y manejar una excepción suele ser una operación relativamente costosa. Por lo tanto, normalmente se deben usar excepciones para eventos excepcionales, no control de flujo normal.

Sin embargo, el rendimiento es solo un factor a tener en cuenta, especialmente en el mundo moderno.Si (por ejemplo) está haciendo algo una vez en respuesta a una acción del usuario, probablemente no importe desde el punto de vista del rendimiento si usa una excepción incluso cuando podría haber hecho un chequeo proactivo, siempre que la excepción ocurra lo suficientemente rápido el usuario no se sobresalta. Pero si está haciendo algo en un circuito cerrado que se ejecutará cientos de miles de veces, o si está escribiendo una aplicación web que puede necesitar manejar una carga enorme, probablemente quiero evitar usar una excepción para un caso normal.

---

¹ Hace más de una década que era responsable de mejoras a un .Net 1.1 "ningún despliegue toque" aplicación en la que la primera excepción que se tienen plenamente tres segundos. Esto era un problema suficiente en un caso de uso que involucraba abrir un archivo que el usuario había pedido y que razonablemente podría no estar allí, tuve que agregar un cheque para la existencia del archivo antes de tratar de abrirlo, lo que normalmente es una mala práctica de programación (solo intente abrir el archivo y manejar la excepción si eso falla), simplemente porque la experiencia del usuario que esperaba que se construyera esa excepción era tan pobre. Pero probablemente ese no sea el mundo en el que vivimos ahora.

Answer 2

try..catch bloques nunca se deben utilizar como una herramienta para el control de flujo del programa.

Lea this thread si no está convencido.

Answer 3

Son bastante baratos a menos que exista una excepción. Por lo tanto, debe evitarlos cuando se espera una excepción, como en su ejemplo anterior.

Creo que las excepciones a la mala entrada de los usuarios son generalmente imprudentes. Las excepciones de falta de memoria u otras fallas inesperadas están bien.

Answer 4

En general, los compiladores modernos imponen solo un costo mínimo en los bloques try a menos que se produzca una excepción. Todavía no deben usarse para el control de flujo del programa, ya que no son tan obvios como las construcciones de flujo estándar. Una excepción es esencialmente equivalente a una declaración COME FROM.

Answer 5

Las excepciones son solo costosas si se lanza una excepción. Estoy seguro de que hay un costo muy bajo para configurar un bloque Try..Catch, pero está muy por encima del costo de no captar la excepción y tener el programa bloqueado. Como han señalado otros, los bloques Try..Catch deben usarse solo en circunstancias excepcionales.

Answer 6

Si bien es cierto que nunca se debe utilizar try..catch para el control de flujo del programa, no tengo conocimiento de ningún problema de rendimiento SI no hay excepciones son en realidad arrojados en el código

Answer 7

Esto depende del idioma, pero hasta donde yo sé en Java, si no se lanza una excepción, no hay costo de rendimiento para tener un try/catch.

Por lo tanto, en su ejemplo de uso de direcciones de correo electrónico validadas previamente, lo que tiene está bien.

Answer 8

La sobrecarga del bloque try es muy baja, por lo que si no se produce una excepción, no debe haber una penalización notable. La sobrecarga principal que ocurre cuando se lanza una excepción es el recorrido de la pila que se lleva a cabo en busca de un controlador: ya que está almacenando en caché la excepción tan cerca de la fuente, dudo que haya mucho de un problema de rendimiento. Lo ideal es que sea capaz de validar sus entradas correctamente de antemano, pero la validación del correo electrónico es bastante complicada, por lo que puede no valer la pena en este caso.

Answer 9

Just to play Devils advocate: he encontrado un gran uso para usar excepciones para el control de flujo: el botón 'cancelar'.

Si tiene una función ejecutándose en algún servicio que puede tomar 10-120 minutos, lo que está haciendo un montón de cosas diferentes, he encontrado que hacer si (hasCanceled) arrojar nueva JobCancelledException() dentro de mi Log () función (que registra en cada paso en el que estoy) para trabajar simplemente increíble. Se libera de la ejecución actual de código y deja de ejecutar el trabajo, exactamente lo que necesito. Estoy seguro de que hay alguna forma mejor de hacerlo, tal vez de alguna manera el uso de eventos, pero para mi caso funciona muy bien (especialmente porque los trabajos no se cancelan regularmente).

Aparte de eso, sin embargo - Estoy 100% de acuerdo en que las excepciones no deben ser utilizados como una herramienta de control de flujo ..

@Kornel - Tengo dos palabras para ese puesto ... $ Santo hit =)

aquí es un simple ejemplo de código de pseudo:

Class Job 
{ 
     Public Run(param1,param2,etc...) 
     { 
      Try 
      { 
        Log("Doing Something") 
        DoSomething() 

         Log("Doing Another") 
         DoAnother() 

         Log("This keeps going, etc, inside of these function we make the same Log calls where it makes sense") 
         Etc() 
        } 
        Catch(JobCancelledException) 
        { 
         status="Cancelled" 
        } 
      } 

       Private Log(ByVal str As String) 
       { 
         MessateToUser(str) 

         if(hasCancelled) 
          throw new JobCancelledException 
      } 

      private SomeEvent_WhenUserPushesCancelButton() 
      { 
         hasCancelled=True 
      } 
} 

Answer 10

es sólo es caro si se produce la excepción, pero eso no es una excusa para usar excepciones como el control de flujo normal.

Si puede validar previamente algo para evitar que ocurra una excepción en primer lugar, hágalo. P.ej. en lugar de lo que usted envió, algo como esto sería preferible:

string invalidAddress = "notvalid@@@@@@lolzors.bomb"; 
return MailAddressValidator.IsValid(invalidAddress); // doesn't cause exception 

La excepción a la regla es cuando usted tendría que rodar su propia versión de un método complicado (por ejemplo,algo que se encuentra en la biblioteca de la clase base que no tiene un método TryParse) solo para evitar una excepción que, en el gran esquema de cosas, simplemente no importa.

Si no está seguro, perfile usando datos representativos. Si es un usuario que ingresa datos en una aplicación de cliente cada dos segundos, no tendrá importancia. Sin embargo, si se trata de un servicio para procesar lotes de miles de direcciones de correo electrónico que pueden venir de cualquier lugar, debe estar seguro de sus suposiciones.