lunes, 3 de diciembre de 2018

Excepciones en Java 2/2

Continuando con el tema de Excepciones que empezamos en el artículo Excepciones en Java 1/2 hablaremos de los bloques try, catch, finally y la declaración try-with-resources la cual es particularmente adecuada para situaciones que usan recursos de Closeable.

Bloque try: El primer paso para construir un controlador de excepciones es encerrar el código que podría generar una excepción dentro de un bloque try.

try {
        código
}bloques catch y finally . . .

El segmento código contiene una o más líneas legales de código que podrían generar una excepción.

Si ocurre una excepción dentro del bloque try, esa excepción es manejada por un controlador de excepciones asociado con él. Para asociar un controlador de excepciones con un bloque try, debe poner un bloque catch después de él.

Bloque catch: Usted asocia los controladores de excepciones con un bloque try al proporcionar uno o más bloques catch directamente después del bloque try. Ningún código puede estar entre el final del bloque try y el comienzo del primer bloque catch.

try {

} catch (ExceptionType name) {

} catch (ExceptionType name) {

}

Cada bloque catch es un controlador de excepciones que maneja el tipo de excepción indicado por su argumento. El tipo de argumento, ExceptionType, declara el tipo de excepción que el manejador puede manejar y debe ser el nombre de una clase que hereda de la clase Throwable. El manejador puede referirse a la excepción utilizando name.

El bloque catch contiene código que se ejecuta cuando se invoca el controlador de excepciones. Los manejadores de excepciones pueden hacer más que solo imprimir mensajes de error o detener el programa. Pueden realizar la recuperación de errores, pedir al usuario que tome una decisión o propagar el error hasta un controlador de nivel superior utilizando excepciones encadenadas.

En Java SE 7 y versiones posteriores, un solo bloque catch puede manejar más de un tipo de excepción. En la cláusula catch, especifique los tipos de excepciones que el bloque puede manejar y separe cada tipo de excepción con una barra vertical (|):

catch (IOException | SQLException ex) {
    logger.log(ex);
    throw ex;
}

Nota: Si un bloque catch maneja más de un tipo de excepción, entonces el parámetro catch es implícitamente final. En este ejemplo, el parámetro catch ex es final y, por lo tanto, no puede asignarle ningún valor dentro del bloque catch.

Bloque finally: El bloque finally siempre se ejecuta cuando el bloque try sale. Esto asegura que el bloque finally se ejecute incluso si ocurre una excepción inesperada. Pero, finalmente, es útil para algo más que el manejo de excepciones: permite al programador evitar que un código de limpieza se omita accidentalmente con una devolución, una continuación o una interrupción. Poner el código de limpieza en un bloque finally es siempre una buena práctica, incluso cuando no se prevén excepciones.

Declaración try-with-resources: La declaración try-with-resources es una declaración try que declara uno o más recursos. Un recurso es un objeto que debe cerrarse después de que el programa haya terminado con él. La declaración try-with-resources asegura que cada recurso se cierre al final de la declaración. Cualquier objeto que implemente java.lang.AutoCloseable, que incluye todos los objetos que implementan java.io.Closeable, puede usarse como un recurso.

static String readFirstLineFromFile(String path) throws IOException {
    try (BufferedReader br = new BufferedReader(new FileReader(path))) {
        return br.readLine();
    }
}

Veamos como se vería los bloques try-catch-finally juntos:

try {
     // Código que puede lanzar una excepción
}catch(TipoExcepcion e){
    // Código para manejar la excepción
}finally {
   // Código que se ejecuta al final se lance o no una excepción
}

En mi repositorio de GitHub de Programación Orientada a Objetos puedes encontrar ejemplos concretos en la sección de excepciones.

Excepciones en Java 1/2

El artículo a continuación es una traducción y resumen del tutorial facilitado por Oracle, con algunos aportes personales.

Partamos por la definición.
Una excepción es un evento, que ocurre durante la ejecución de un programa, que interrumpe el flujo normal de las instrucciones del programa. 
Ahora bien, ¿Qué pasa cuando ocurre durante la ejecución uno de estos eventos?, realmente lo que ocurre es que el método donde se origina la excepción crea un objeto y lo entrega al sistema de tiempo de ejecución. El objeto, llamado objeto de excepción, contiene información sobre el error, incluido su tipo y el estado del programa cuando ocurrió el error. Crear un objeto de excepción y entregarlo al sistema de tiempo de ejecución se llama lanzar una excepción.

Después de que un método lanza una excepción, el sistema de tiempo de ejecución intenta encontrar algo para manejarlo. El conjunto de posibles "cosas" para manejar la excepción es la lista ordenada de métodos que se habían llamado para llegar al método donde ocurrió el error. La lista de métodos se conoce como la pila de llamadas.


El sistema en tiempo de ejecución busca en la pila de llamadas un método que contenga un bloque de código que pueda manejar la excepción. Este bloque de código se llama un controlador de excepciones (exception handler). La búsqueda comienza con el método en el que se produjo el error y continúa a través de la pila de llamadas en el orden inverso en que se llamaron los métodos. Cuando se encuentra un controlador adecuado, el sistema de ejecución pasa la excepción al controlador. Un controlador de excepciones se considera apropiado si el tipo del objeto de excepción lanzado coincide con el tipo que puede manejar el controlador. Se dice que el controlador de excepciones elegido captura la excepción. Si el sistema en tiempo de ejecución busca exhaustivamente todos los métodos en la pila de llamadas sin encontrar un controlador de excepción apropiado, como se muestra en la siguiente figura, el sistema en tiempo de ejecución (y, en consecuencia, el programa) termina.


El requisito de captura o especificación

Java válido debe cumplir con el requisito de captura o especificación. Esto significa que el código que podría generar ciertas excepciones debe estar incluido por uno de los siguientes:

  • Una declaración try que atrapa la excepción. try debe proporcionar un controlador para la excepción (catch).
  • Un método que especifica que puede lanzar la excepción. El método debe proporcionar una cláusula throws  que enumera la excepción o excepciones que puede lanzar el método.
El código que no cumple con el requisito de captura o especificación no se compilará.

No todas las excepciones están sujetas al requisito de captura o especificación. Para entender por qué, debemos observar las tres categorías básicas de excepciones, de las cuales solo una está sujeta al Requisito.

  1. Excepción comprobada (checked exception) : Estas son condiciones excepcionales que una aplicación bien escrita debe anticipar y recuperar. Las excepciones comprobadas están sujetas al requisito de captura o especificación. Todas las excepciones son excepciones verificadas, excepto aquellas indicadas por Error, RuntimeException y sus subclases.
  2. Error :  Son condiciones excepcionales que son externas a la aplicación y de las cuales la aplicación generalmente no puede anticipar o recuperar. Los errores no están sujetos a los requisitos de captura o especificación. Los errores son aquellas excepciones indicadas por Error y sus subclases.
  3. Excepción de tiempo de ejecución (RuntimeException) :  Son condiciones excepcionales que son internas a la aplicación y de las cuales la aplicación generalmente no puede anticipar o recuperar. Estos suelen indicar errores de programación, como errores lógicos o uso incorrecto de una API. Las excepciones de tiempo de ejecución no están sujetas al requisito de captura o especificación. Las excepciones de tiempo de ejecución son aquellas indicadas por RuntimeException y sus subclases.
Debido a que este artículo se ha extendido un poco lo dejare hasta acá y seguiremos en Excepciones en Java 2/2 donde abordaremos los bloques necesarios para controlar una excepción.

domingo, 2 de diciembre de 2018

Refactorización

Refactorización es el proceso de cambiar un sistema de software de tal manera que no altera el comportamiento externo del código pero mejora su estructura interna. Es una forma disciplinada de limpiar el código que minimiza las posibilidades de introducir errores. (Si quieres saber más sobre código limpio te invito a leer este artículos)

Con la refactorización puede tomar un mal diseño, incluso un caos, y volver a trabajar en un código  bien diseñado. Cada paso es simple, incluso simplista. Sin embargo, el efecto acumulativo de estos  pequeños cambios puede mejorar radicalmente el diseño. 

El problema de la refactorización es que puede ser costoso y altamente peligroso, puesto que se debe cambiar código que funciona por código que no sabemos si puede funcionar. Como solución a este inconveniente se recomienda que el código tenga pruebas unitarias automatizadas.

En este post solo veremos algunos método de refactorización, si quieres conocer un catalogo más amplio y detallado puede ingresar a https://www.refactoring.com/catalog/

Los métodos son:

  1. Rename: Consiste en cambiar el nombre de variables, métodos o clases según sea el caso con el fin de tener un código limpio, de esta forma el código sea más legible, mantenible entre otras características.
  2. Extract Function: En ocasiones se tienen métodos que tienen muchas líneas, realiza más responsabilidades de las que debería hacer o simplemente no queda claro para que se quiere ese método. Para solucionar lo anterior se debe crear un método o métodos donde se realice la operación que se quiere extraer del método principal con el fin de separar las responsabilidades o entender mejor el método.
  3. Inline: Un caso especifico del método en linea se presenta cuando tenemos uno o mas métodos cuyos códigos son lo suficientemente auto-explicativos como para poder prescindir de ellos. Bastará con sustituir las llamadas al método por el cuerpo de dicho método; pero esto también ocurre con las variables, en ocasiones se tiene una variables que solo se usa para almacenar un valor y posteriormente retornarlo.
  4. Extract Class: Cuando una clase hace el trabajo de dos, resulta torpe. En su lugar, cree una nueva clase y coloque los campos y métodos responsables de la funcionalidad relevante en ella.
  5. Encapsulated Fields: Consiste en cambiar los modificadores de acceso que se requieran. Por ejemplo se cambian métodos públicos a privados porque solamente se acceden desde la misma clase.

El camino es largo y conlleva aprender más métodos y adquirir nuevas destrezas pero te aseguro que dando este primer paso veras cambios significativos en tu código.

Para poner en práctica estos métodos puedes ingresar a mi repositorio https://github.com/cedaniel200/Refactorizacion donde encontraras una series de ejercicios simples para afianzar los conceptos vistos.

Adicionalemente te recomiendo este excelente libro de Martin Fowler llamado Refactoring: Improving the Design of Existing Code 1era Edición o su 2da edición.

Espero que si realizas mis ejercicios propuestos, al finalizarlos, me dejes un comentario con la retroalimentación de los mismos.

Para finalizar te recomiendo este otro artículo donde hablo acerca de los principios SOLID una destreza que debes adquirir si sigues el camino para ser un excelente desarrollador de software.

Instalación NodeJS

Ingresamos a la página oficial de NodeJS donde lo descargaremos  https://nodejs.org/en/download/ Escogemos el instalador que se ajuste a ...