Los filtros de excepción se introdujeron en C# cuando se lanzó la versión 6. Estas cláusulas determinan cuándo se debe aplicar una determinada cláusula de captura . En pocas palabras, cuando la expresión en el filtro de expresión se evalúa como verdadera, la cláusula catch realiza sus acciones normales sobre la excepción dada; de lo contrario, se salta.
Hay una amplia gama de situaciones en las que puede querer, o necesitar, aplicar filtros de excepción. La mayoría de las veces, los uso para registrar excepciones específicas que son relevantes para la ejecución de mis aplicaciones. En aquel entonces, escribí una pequeña aplicación que verificaba, para la empresa en la que trabajaba en ese momento, las redirecciones de sus sitios web y si funcionaban correctamente. Se hizo teniendo cuidado con el código 301 en la respuesta HTTP .
Hay un aspecto importante del filtrado, es la palabra clave cuando , que le proporciona una evaluación lógica de la excepción y la condición que está buscando.
Veámoslo de esta manera.
123456try{...}catch(System.Net.Http.HttpRequestException e)when(e.Message.Contains("404")){return "Site is not available";}csharp
En el bloque try , imaginemos que tenemos un cliente HTTP tratando de recuperar un sitio web. Cuando el servidor web responde a la presencia de algunos errores, como si el sitio se ha movido o el contenido no está disponible, se planteará una excepción. Esta excepción es entonces capturada con el bloque catch . El filtro when asegura que sólo si el Mensaje contiene la cadena 404 se ejecutará el bloque. Por lo tanto, la lógica dice que si hay una excepción, entonces sólo nos preocupamos por la excepción siempre y cuando contenga la cadena apropiada.
Hay pros y contras de este enfoque. Se basa en el supuesto de que cualquier otra excepción es irrelevante desde la perspectiva de la ejecución de las aplicaciones. Podría ser cierto, pero necesitamos verlo desde una perspectiva diferente.
Puede haber casos en los que se quiera que estas aplicaciones atómicas ejecuten una sola tarea. En ese caso, cualquier otro mensaje es irrelevante para esa aplicación debido a la naturaleza de la aplicación. Lo único que importa para la aplicación será el resultado que produzca.
Hay múltiples paradigmas que deben ser tomados en consideración cuando usamos filtros, y estas decisiones reverberarán a lo largo de todo nuestro proceso de desarrollo en relación con la aplicación.
A partir de nuestro primer ejemplo, hay formas de atrapar múltiples tipos de excepciones y filtrarlas.
Modifiquemos nuestra función añadiendo otra excepción.
12345doubleDivide(double a,double b){if(b ==0){thrownewMyException("Bueno esto es incómodo!");}if(b ==10){thrownewMyException("El segundo valor es exactamente 10!");}regresar a / b;}csharp
Ahora, manejaremos las excepciones apropiadamente. Cuando nuestro mensaje contiene el awkward , queremos ejecutar el primer bloque catch . Cuando nuestro mensaje contiene el awkward , queremos ejecutar el segundo bloque catch . También queremos tener una rama única que atrape cualquier otra cosa.
12345678910try{ Console.WriteLine(Divide(10,10));}catch(MiExcepción e)when(e.Message.Contains("awkward")){ Console.WriteLine($"Bueno esto no es lo que esperaba: {e.Message}");}catch(MiExcepción e)when(e.Message. Contains("exactly")){ Console.WriteLine($"Well something else has happened: {e.Message}");}catch(Exception e){ Console.WriteLine($"This was not really handled!");}finally{ Console.WriteLine("I$0027m gonna be executed anyways!");}csharp
Llamando al código anterior se obtienen los siguientes resultados.
Como pueden ver, el segundo bloque de captura entró en juego.