Sesión 9. TEMA 11 Clases abstractas. Manejo de errores y excepciones

(1)

Sesi´

on 9. TEMA 11 Clases abstractas. Manejo de

errores y excepciones

Fundamentos de Inform´atica

Jos´e Jaime Noguera Noguera

(2)

Contenidos

1 Introducci´on

2 Clases abstractas

3 Errores y excepciones

(3)

Temario

Este Tema tiene dos partes. La primera corresponde a clases abs-tractas (apartados 10.3 y 10.4 de la edición 5, o 12.3 y 12.4 de la edición 6). Las secciones del libro tratan sobre unas clases que se explican en apartados que no entran, con lo cual es complicado se-guir los razonamientos. Lo importante es centrarse en los conceptos clase abstracta y método abstracto.

La segunda parte del tema hace referencia al manejo de errores y excepciones (tema 12 del libro en la edici´on 5 o tema 14 en la edici´on 6.)

(4)

Clase abstracta

Una clase abstracta es una clase de la cual no se van a crear ins-tancias, es decir no tendremos objetos de dicha clase. Su objetivo es ser superclase de otras subclases. Debemos tener en cuenta:

Para declarar una clase como abstracta se debe incluir

abstractantes de class, por ejemplo public abstract class

NombreClase

No se pueden crear instancias de una clase abstracta. Si utilizamosnew NombreClase()nos dar´a un error.

una clase abstracta puede contener métodos abstractos (los explicamos después) y también métodos no abstractos (o concretos).

Si una clase contiene m´etodos abstractos necesariamente debe ser abstracta.

(5)

M´

etodos abstractos

Se definen como

abstract public/protected TipoRetorno nombreMetodo(lista

de par´ametros);

Caracter´ısticas

Están formados únicamente por una cabecera de un método, sin que exista cuerpo. Terminan en punto y coma.

Solo pueden existir dentro de una clase abstracta,

Est´an pensados para que sean sustituidos e implementados en las subclases. Si esto no se hace la subclase deber´a

(6)

M´

etodos y clases abstratas

Nota 1

Su nombre proviene de una mala traducción al español, ya que en inglésabstractes resumen y es esto lo que realmente se deber´ıa entender. Las clasesabstractson una clase resumen para sus subclases.

Nota 2

Tanto en la definici´on de clase abstracta como de m´etodo

abstracto el modificador de acceso (public) y la palabra reservada

abstractpueden intercambiarse. El orden mostrado anteriormente

(7)

Ejemplo

Retomando el ejemplo de la sesión anterior podemos hacer las si-guientes modificaciones para incluir clases y métodos abstractos (descargar código):

Definir Veh´ıculo como clase abstracta, entendiendo as´ı que en el taller s´olo podemos crear objetos de tipo Coches o Motos pero no veh´ıculos; public abstract class Vehiculo

Definir como abstracto el m´etodo mostrarInfo():abstract public void mostrarInfo();

Completar el m´etodo ya implementadomostrarInfo()de las subclases para que imprima la marca y la matr´ıcula.

(8)

Diagrama de clases

Observar que BlueJ nos informa de que las clases son abstractas con el identificador«abstract». Adem´as cuando creamos una clase nueva nos permite elegir la opci´on de clase abstracta.

(9)

Tratamiento de errores y excepciones

Este tema es bastante confuso ya que al ser muy extenso se dan indicaciones imprecisas del tipo: esto no es una ciencia exacta o esto no lo explicamos porque excede los objetivos de este libro, ... Adem´as la forma de explicarlo difiere seg´un el tutorial o libro que leas. Para aumentar los problemas has de tener en cuenta:

A lo largo del tema aparecen conceptos que no has estudia-do (ya que hemos saltaestudia-do temas y secciones): TreeMap, List, SortedMap, interfaces...

Por tanto, la recomendaci´on es centrarse en entender los conceptos generales que pueden aparecer en el test y no pretender entender todo el tema al detalle.

(10)

Objeto cliente y objeto servidor

La nomenclatura de objeto cliente y objeto servidor hace referencia a lo siguiente:

Objeto servidor: es un objeto cualquiera que dispone de m´etodos en el c´odigo de la clase a partir de la cual ha sido instanciado.

Objeto cliente: es un objeto que hace uso de un método del objeto servidor. Es decir, dentro del objeto cliente se llama a un método del objeto servidor (mediante notación de punto).

(11)

Errores y excepciones

Un error o excepción se produce cuando al compilar o ejecutar un programa se llega a una situación en que Java no sabe cómo actuar. Por ejemplo, se divide por 0, o se intenta abrir un fichero que no exis-te... Ante estas situaciones cabe preguntarse quién es el responsable de este error y quién debe resolverlo. Imaginemos un objeto clien-te que inclien-tenta ejecutar un método con un String que en realidad requer´ıa unint:

¿Deber´ıa haberse previsto estas situaciones desde el objeto servidor y haber introducido c´odigo para evitarlo?

(programaci´on defensiva)

¿Deber´ıa el cliente haber evitado el error siendo ”consciente” del tipo de par´ametro necesario?

(12)

Errores y excepciones

Hay diversas maneras de tratar estos problemas:

Informar al usuario de que se ha producido un error (¿y si el usuario no es un humano o no entiende lo que se le dice?). Devolver valores booleanos para asegurarnos de que un m´etodo ha realizado su cometido.

Devolver valoresnull en vez de objetos en métodos tipo get. Sin embargo estas medidas son normalmente insuficientes y Java dispone de mecanismos más eficientes: la generación de objetos es-pec´ıficos que informen del error.

(13)

Errores y excepciones

Cuando a un objeto servidor, un cliente le solicita ejecutar uno de sus m´etodos, pero el primero no puede terminar la llamada del segundo, entonces el objeto servidor puede generar un objeto excepci´on:

El objeto excepci´on representa los detalles del fallo de un programa.

El error lo descubre el objeto servidor y genera el objeto excepci´on.

La recuperaci´on del error, en caso de intentarlo, se realiza en el cliente, ya que si el servidor puede por s´ı mismo recuperarse del error, no tiene sentido crear el objeto excepci´on.

El objeto excepci´on es una instancia de una clase de la jerarqu´ıa de clases Throwable.

(14)

(15)

Jerarqu´ıa de clases

Error: problema grave que no debemos tratar de solucionar:

OutOfMemoryError (memoria agotada), InternalError (error de la JVM)...

Exception: excepciones que podr´ıan evitarse o tratarse. Se

dividen en:

RuntimeException y sus subclases: Excepciones NO COMPROBADAS (unchecked).

El resto de subclases de Exception: excepciones COMPROBADAS (checked).

(16)

Excepciones comprobadas y no comprobadas

COMPROBADAS: situaciones en el que el objeto cliente de-ber´ıa esperar que una operación pueda fallar y debe comprobar si ésta ha tenido éxito. Deben utilizarse para situaciones que no puede evitar el programador, como problemas de entrada/sa-lida: FileNotFoundException, ZipException, MalformedURLEx-ception ...

NO COMPROBADAS: situaciones en que el objeto cliente nun-ca deber´ıa esperar que fallasen y por tanto no necesita com-probar si las operaciones han tenido ´exito. Corresponden a fa-llos que comete el programador: NullPointerException, ArrayIn-dexOutOfBoundsException, ArithmeticException, NoSuchEle-mentException, ClassCastException...

(17)

Lanzando excepciones

Vamos a ver un ejemplo extremadamente sencillo para ilustrar qu´e significa lanzar una excepci´on:

Tenemos una clase Servidor y una clase Cliente. En la clase Servidor hay un método que si recibe un parámetro nulo lanza una excepción.

Crearemos un objeto tipo Servidor y uno Tipo Cliente. Desde el objeto cliente llamaremos al método del objeto servidor con parámetro nulo y se producirá una excepción. A continuación mostramos el código. Prestar atención a cómo se lanza una excepción:

throw new TipoExcepcion(”Cadena opcional que da informaci´on

(18)

(19)

(20)

(21)

(22)

Ejemplo: ejecuci´

on

Al ejecutar el Lanzador se lanza una excepción (se crea un objeto tipo excepción) y el programa finaliza en esa l´ınea de código. Observar las informaciones que ofrece el terminal y el editor de BlueJ:

(23)

Ejemplo: impidiendo crear objetos

En el constructor tambi´en podemos lanzar excepciones, evitando as´ı que se creen objetos con estados iniciales inv´alidos. Por ejemplo modificamos nuestro constructor de la siguiente manera:

(24)

Ejemplo: ejecuci´

on

Si ejecutamos el lanzador con la instrucci´on:

Servidor objetoServidor=new Servidor(”casa”);

(25)

Ejemplo: excepciones no comprobadas

Las anteriores excepciones son no comprobadas, ya que pueden ser solucionadas modificando el código, es decir el programador puede evitarlas. Este tipo de excepciones no requieren ninguna compro-bación por parte del compilador. La ejecución se detiene y es el programador el que debe solucionar el problema. Otro ejemplo de este tipo de excepciones ser´ıa por ejemplo la que se produce en el siguiente método que añadimos a nuestra clase Cliente:

(26)

(27)

Ejemplo: ejecuci´

on

Ejecutamos el Lanzador a˜nadiendo la instrucci´on:

objetoCliente.excepcionNoComprobada();

Observar que es ahora la división la que lanzará una excepción tipo

(28)

Excepciones comprobadas

Todo lo que veamos ahora para excepciones comprobadas es igual-mente v´alido para excepciones no comprobadas. Sin embargo el tra-tamiento de excepciones solo es obligatorio con las comprobadas, cuyo uso requiere comprobaciones adicionales por parte del compi-lador. En concreto cl´ausulasthrowe instrucciones try. Siguiendo el estilo del libro, no utilizaremosthrow y try en las no comprobadas (aunque puede hacerse).

En parte esto es lógico, ya que si la excepción es no comprobada, es el programador el que debe mejorar el código, mientras que si es comprobada es fruto de algo que escapa al control del programador. Las cláusulas throw y try le indican a Java qué hacer en dichos casos.

(29)

Excepciones comprobadas

Tenemos dos opciones para excepciones comprobadas:

Relanzarla mediante la cláusula throws: en este caso desde el método cliente se propaga la excepción al método que ha llamado a este último. Si en el método al que se ha propagado la excepción no hay una rutina que la trate se repite el proceso. Si se llega al método inicial que ha llamado a todos los demás y no se trata la excepción, la ejecución de detiene

Capturarla mediante las instrucciones try/catch. Es la más interesante y la que deber´ıamos utilizar, ya que se evita la in-terrupción de la ejecución.

(30)

Excepciones comprobadas: relanzarla

El m´etodoleeArchivo()tiene como finalidad leer un archivo llamado

archivo.txt. Si no se encuentra se produce una excepci´on y en este caso se relanza:

(31)

Excepciones comprobadas: relanzarla

Si ejecutamos el código (creando un objeto y ejecutando el método) obtenemos que la ejecución se para, ya que la excepción se relanza. En este caso, dado que el método que lo ha llamado (main) tampoco tiene una rutina para tratar la excepción, entonces se detiene.

(32)

Excepciones comprobadas: capturarla

(33)

Excepciones Comprobadas: capturarla

En este caso en el bloque try se genera una excepción, entonces la ejecución pasa al boque catch. Observar que la ejecuciónno se

(34)

Excepciones Comprobadas: capturarla

El objeto excepción que se ha creado, dado que es de tipo IOExcep-tionha sido capturado en la variable e (este es el nombre del objeto, se puede utilizar cualquier nombre). Como todo objeto tendrá una serie de métodos definidos en la claseIOException(o heredados de sus superclases). Los más utilizados son:

getMessage(): devuelve un mensage detallado sobre la excepci´on que ha ocurrido.

printStackTrace(): devuelve la traza de la pila de llamadas hasta llegar al error.

Aqu´ıpuedes ver más métodos o bien en la documentación de la clase

(35)

try/catch

try{

se ejecuta primero }

catch(TipoExcepcion nombre){

se ejecuta si hay una excepcion en el bloque try }

finally{

se ejecuta siempre }

Podemos poner uno, varios o ning´un catch (pero debe aparecer finally).

finally es opcional (siempre que est´e el catch). Se pueden anidar varios try/catch/finally

(36)

Captura de varias excepciones

try{

se ejecuta primero

}catch(TipoExcepcion1 nombre1){

se ejecuta si hay una excepcion en el bloque try y la excepcion es de tipo TipoExcepcion1

}catch(TipoExcepcion2 nombre2){

se ejecuta si hay una excepcion en el bloque try, la excpecion no es de tipo TipoExcepcion1 pero es de tipo TipoExcepcion2

}

Si TipoExcepción1 fuese superclase de TipoExcepción2, el segundo catch nunca se ejecutar´ıa ya que la excepción se capturar´ıa (en caso de hacerlo) en el primero. Las superclases siempre deben situarse después de sus subclases.

(37)

Multicaptura

En Java 7 se permite gestionar m´ultiples excepciones en un solo catch:

try{

se ejecuta primero

}catch(TipoExcepcion1 | TipoExcepcion2 nombre1){

se ejecuta si hay una excepcion en el bloque try y la excepcion es de tipo TipoExcepcion1 o TipoExcepcion2 }

(38)

try con recursos

En Java 7 se permite una nueva estructura utilizada principalmente para cerrar archivos autom´aticamente una vez completada la ins-trucci´ontry:

try(FileWriter wrtiter=new FileWriter(filename)){ se ejecuta primero y no es necesario poner una

instruccion writer.close() }catch(IOException e){

se ejecuta si hay una excepcion en el bloque try y la excepcion es de tipo IOException

}

(39)

Definici´

on de nuevas clases de excepci´

on

Podemos definir nuestras propias clases de excepci´on, creando sub-clases de la claseException:

public class MiExcepcion extends Exception{ ...

}

A partir de esta subclase podemos lanzar y capturar excepciones

tipoMiExcepcion.

Aparte de los ejemplos del libro, si quieres ver otros (adem´as de ser un buen repaso de todo lo visto):excepciones1,excepciones2

(40)

Pregunta

¿Es correcto lo siguiente?

abstract public class Clase(){ ...

(41)

Respuesta

abstract public class Clase(){ ...

}

S´ı es correcto. Es el constructor de una clase abstracta. El orden de abstractypublic no importa.

(42)

Pregunta

abstract public void metodo(){ ...

(43)

Respuesta

abstract public void metodo(){ ...

(53)

Respuesta

Si las únicas lineas para mostrar algo por pantalla son las que apare-cen aqu´ı y sabiendo que en elbloque de sentencias 1 no se produce ninguna excepción, ¿Qué se muestra por pantalla?

Si las únicas lineas para mostrar algo por pantalla son las que apa-recen aqu´ı y sabiendo que en elbloque de sentencias 1 se produce una excepción que es subtipo de TipoExcepcion, ¿Qué se muestra por pantalla? try{ bloque de sentencias 1 System.out.print("hola"); }catch(TipoExcepcion e){ bloque de sentencias 2 System.out.print("adios"); }finally{ System.out.print("buenas"); } System.out.print("fin"); Se muestra: adiosbuenasfin