Escuché que en lugar de lanzar excepciones y atraparlas en try/catch block, es más razonable devolver null en los métodos porque try/catch es una operación que consume recursos. ¿Es esto cierto?¿Es try/catch es una operación que consume recursos?
Es cierto lo que ha escuchado: una excepción lanzada y atrapada es más costosa que devolver null. Pero, considere también el gasto de mantener a todas las personas que llaman de su código.Tendrán que verificar null, y si alguna vez desea agregar más tipos de errores, tendrá que modificar las personas que llaman.
Use excepciones para condiciones excepcionales. Si un error es un caso común o habitual, entonces no es excepcional: devuelve un código de estado.
Para mí, intentar atrapar es solo una forma de atrapar ERRORES, si es solo porque la función no se puede ejecutar, usaría un valor de retorno.
Sí, arrojar y atrapar excepciones podría ser una operación costosa. Las excepciones deben arrojarse solo en casos excepcionales (casos que ocurren raramente). Por ejemplo, evite lanzar excepciones al validar alguna entrada del usuario cuando puede devolver verdadero/falso.
try/catch consume recursos triviales, sin embargo, lanzar una excepción es relativamente costoso. Las excepciones solo deben lanzarse en circunstancias excepcionales, y no deben ser un problema de rendimiento si se usan con cuidado.
Probar/atrapar solo requiere una gran cantidad de recursos si se lanza una excepción, de lo contrario, es prácticamente nula. Úselos cuando limpien el programa. La devolución nula también puede estar bien. Depende de
Debe lanzar Excepciones cuando la condición en cuestión es una condición excepcional que un objeto de excepción puede ser útil para pasar información de respaldo a la pila de llamadas.
Debe devolver null de métodos en lugar de un valor esperado cuando ese es un valor apropiado, no excepcional que significaría "nada aquí", o algún equivalente.
Para los "errores" no excepcionales en los que no es apropiado un null, a menudo puede hacer algo diferente.
No siempre es cierto y depende de la situación. Imagine que puede obtener tres o más tipos de errores dentro de un método. Entonces, devolver el valor 'nulo' individual no le indicará al código del cliente el tipo de error.
Además, simplemente regresar de la función no siempre es lo que quiere hacer en términos de control de flujo.
Incluso si es cierto (hasta cierto punto), es otro caso (malo) de optimización prematura para usar eso como una razón para evitar excepciones en general.
Las excepciones son para comunicar las condiciones que probablemente se manejarán más arriba en la pila de llamadas en lugar de la llamada inmediata. Si tiene tal condición, debe usar una excepción.
+1 Muy cierto 'Incluso si es cierto (hasta cierto punto), es otro (malo) caso de optimización prematura utilizarlo como una razón para evitar excepciones en general. – Favonius
Como han señalado otros, las excepciones son costosas cuando se capturan, pero solo poner la captura de prueba en su código es barato (excepto cuando se pone en un bucle, por ejemplo).
Aunque, ignorarlos es un signo de optimización prematura, ya que solo devolver null o false puede obstaculizar el flujo de control, ya que su código se convertirá en un desastre.
He visto toneladas de código if (something != null && something.exists() && something.isTrue()) en mi vida, y no es bonito.
+1 Aunque podría ser costoso si try catch se usa dentro de un bucle. – Favonius
@Favonius: mejor poner un lazo dentro de la captura de prueba. – darioo