Siguiendo con la temática de un post reciente de braulio:
Desde PHP 5 podemos hacer el uso de excepciones como casi en cualquier lenguage de programación, ¿excelente verdad? Pero hay que tener en cuenta que aunque las excepciones sean una gran herramienta, también podrían ser peligrosas cuando son usadas indebidamente, por ejemplo nuestra aplicación podría consumir muchos recursos.
La misma recomendación se aplica para cualquier lenguaje en realidad, no solo PHP, por ejemplo hoy mismo salió publicado un artículo en favor de la utlización del método TryParse por sobre el método Parse.
Un ejemplo simple
Supongamos que necesitamos obtener el ID de un producto vía QueryString, convertirlo a entero para luego poder llamar al método de una clase para buscar el producto en la base de datos, en .NET 1.1 podríamos utilizar el siguiente código:
protected void Page_Load(object sender, EventArgs e)
{
try
{
int productID = int.Parse(Request.QueryString["productID"]);
// lógica para buscar el producto va aquí...
}
// el valor pasado por QueryString no es un número
catch (Exception ex)
{
throw ex;
}
}
Ahora bien, no sería extraño que alguien intente pasar el valor "productID=$%()", lo que resultaría en una excepción, por lo que el proceso de nuestra aplicación comenzaría a utilizar más y más recursos sin ningún sentido, peor aún, ni hablar si estamos logeando –algo que considero una práctica recomendada– (por ejemplo a un archivo de texto/base de datos, o enviando un mail a la persona responsable) cada vez que ocurre un error, como ven el problema empieza a escalar.
La solución
protected void Page_Load(object sender, EventArgs e)
{
int productID;
if (int.TryParse(Request.QueryString["productID"], out productID))
{
// lógica para buscar el producto
}
else
{
// el valor no es un número
}
}
El segundo ejemplo, es obviamente una solución mucho más inteligente, el método TryParse simplemente devuelve False, sin devolver una excepción.
Es importante entender que sólo deberíamos "tirar" una excepción cuando ocurre un imprevisto (en este caso aunque no es lo esperado es absolutamente posible que el valor de productID que proviene del QueryString no sea un número), algo fuera de lo normal (un error que no pudimos predecir) o algo para lo cual no existe una solución para que la aplicación siga funcionando (algo totalmente terminal, por ejemplo que falle el servidor de base de datos)
Espero sea útil.