Buenas Prácticas: Definición de Excepciones Propias

Inicio una nueva saga de opinión relacionado con las buenas prácticas. La primera, está relacionada con la programación, en concreto con la creación de excepciones propias, relacionadas con las clases que vayamos generando.
Para los que no conozcan o no hayan trabajado con excepciones, me ahorro la definición y me uno a la reutilización de código: https://es.wikipedia.org/wiki/Manejo_de_excepciones
Una vez situados en el contexto, paso a describir la práctica con un ejemplo.
Supongamos que utilizamos una clase que nos ayudará a extraer datos de un dispositivo GPS, que en un alarde originalidad vamos a llamar “GPS”. La clase tiene varios métodos y no tenemos acceso al código, ya que la importamos a traves de una dll.
1) CountSatelitesDisponibles(): Retorna el total de satélites disponibles para el dispositivo GPS
2) GetLongitud(): Retorna la longitud actual
3) GetLatitud(): Retorna la latitud actual
4) Conectar(): Conecta el dispositivo GPS
5) Desconectar(): Desconecta el dispositivo GPS
6) IsConexion(): Retorna verdadero si hay conexión con el gps, retorna falso en caso contrario
Si nos pusiéramos en marcha para utilizar la clase en nuestra aplicación, podrí­amos crear algo similar a esto (uso sintaxis C#)
public void miMetodo()
{
    try
    {
        GPS objeto = new GPS();
        objeto.Conectar();
        if (objeto.IsConexion())
        {
            if (objeto.countSatelitesDisponibles()>=4)
            {
                // mostrarPorPantalla es un
                // método que genera una pantalla
                // emergente
                mostrarPorPantalla(objeto.GetLongitud());
            }
        }
    }
    catch(Exception ex)
    {
        // tratarExcepcion es un método
       // que se encarga de mostrar el
       // mensaje por pantalla.
        tratarExcepcion(ex);
    }
    finally
    {
        objeto.Desconectar();
    }
}
¿Qué ocurrirí­a si se produce alguna excepción en la ejecución del código? Pues se harí­a el catch con el objeto Exception, y tratarExcepcion se encargarí­a de mostrar un mensaje por pantalla. Si hemos tenido suerte que en la definición de la clase GPS el desarrollador incluyó una excepción genérica con un mensaje de texto, con suerte almenos en ex.Message tendremos parte de la descripción del error. Es todo lo que podrí­amos hacer desde la llamada a la clase GPS con las herramientas que nos brinda. No somos capaces de tratar la excepción en la conexión, o en el recuento de satélites desde nuestro código, ya que no sabemos cíºando se produjo el error allí­ (si hay mensaje podrí­amos mirar el mensaje… pero eso es una cutrez nada recomendada y menos en este artí­culo)
A continuación dejo aquí­ lo que serí­a la definición del método Conectar de la clase GPS lanzando excepciones genéricas
public void Conectar()
{
    try
    {
        // Código encargado de conectar el dispositivo GPS
    }
    catch(Exception ex)
    {
        throw new Exception(“Error al conectar”);
    }
}
¿Y si en lugar de utilizar excepciones genéricas dejáramos definidas excepciones propias de la clase y las lanzáramos a estas en lugar de usar la excepción genérica?
public void Conectar()
{
    try
    {
        // Código encargado de conectar el dispositivo GPS
    }
    catch(Exception ex)
    {
        throw new NoSeHaPodidoConectarConElGPSException();
    }
}
public class NoSeHaPodidoConectarConElGPSException:Exception
{
    public NoSeHaPodidoConectarConElGPSException() : base(“Error Conectando”) { }
}
Esto ya es otra cosa, ya que ahora, desde nuestra aplicación podremos tratar exáctamente cual ha sido la excepción que se ha producido. Fijaros:
public void miMetodo()
{
    try
    {
        GPS objeto = new GPS();
        objeto.Conectar();
        if (objeto.IsConexion())
        {
            if (objeto.countSatelitesDisponibles()>=4)
            {
                // mostrarPorPantalla
                // es un método que genera
                // una pantalla emergente
                mostrarPorPantalla(objeto.GetLongitud());
            }
        }
    }
    catch(GPS.NoSeHaPodidoConectarConElGPSException ex)
    {
        //mandarEmailServicioTecnicoGPS se 
        //encarga de coger la excepción,
        // generar un email con la información
        // que incluye y mandarlo al técnico
       // con menor carga de trabajo de nuestra
       // organización.
        mandarEmailServicioTecnicoGPS(ex);
    }
    catch(Exception ex)
    {
        // tratarExcepcion es un método que
        // se encarga de mostrar el mensaje
        // por pantalla.
        tratarExcepcion(ex);
    }
    finally
    {
        objeto.Desconectar();
    }
}
¿Mucho mejor no? ¿Merece o no merece la pena el definir excepciones propias?
Saludos.
Miguel.

3 thoughts on “Buenas Prácticas: Definición de Excepciones Propias”

  1. Y el performance?, el uso de excepciones onc try catches para casos muy excepcionales, como liberaicond erecursos, no es la mejor manera… sedeeb tomar en cuenta ello.

  2. Hola Max,
    Como siempre pues habrá que valorar ventajas e incovenientes respecto a nuestra solución.
    Si necesitamos un control exhaustivo de excepciones porque para nuestra aplicación es crucial, habrá que sacrificar algo de performance. Si en nuestra aplicación el rendimiento es algo vital, está claro que habrá que tratar este tema de forma algo más adaptada.
    Gracias por la aportación.
    Un saludo.
    Miguel.

  3. Solo agredecer por el articulo… recien estoy aplicando el tema de las excepciones y ejemplos concretos como este ayuda a comprender su importancia.
    Saludos!

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.