Duda sobre herencia, sobreescritura y excepciones

[javimartinez]

Hola a todos

Estoy haciendo un programa en Java y me ha surgido el siguiente problema: necesito implementar una clase llamada MiArrayList, la cual debe de tener todos los metodos de ArrayList, pero, bajo ciertas condiciones, lanzar una excepción del tipo MiException (la cual extiende Exception).

Mi primera idea fue la de sobreescribir los métodos con el siguiente código (supongamos el método remove):

--------------
//La primera excepción la lanza el método de ArrayList y la segunda es la mía
public Object remove(int index) throws IndexOutOfBoundsException, MiException {
if (mi condicion)
throw new MiException("Error");
else
return super.remove(index);
}
----------------

Sin embargo, al compilar me da un error indicandome que el método remove sobreescribe un método (el remove de ArrayList) el cual no lanza MiException.

¿Hay alguna forma de hacer esto?


Pensando que la respuesta a la preguta anterior puede ser negativa he realizado una clase que no extiende a ArrayList, si no que tiene un atributo de este tipo y realiza sobre el las operaciones (para lo cual he tenido que implementar todos los metodos de ArrayList en mi clase). Sin embargo, el problema de esta solución radica en que, al no heredar de ArrayList, mi clase ya no es una Collection, por lo que a la hora de pasarla como parametro a metodos de otras clases no valdría.

¿Hay alguna otra forma de resolver el problema?

Gracias y un saludo

[kripton]

Hola javimartinez!!!

Otra solución sería hacer:

public Object remove2(int index) throws IndexOutOfBoundsException, MiException {
if (mi condicion)
throw new MiException("Error");
else
return super.remove(index);
}


De esta forma el compilador no se te quejara de que añades nuevas excepciones al método padre, pero internamente lo seguirias usando. Ademas, volveras a heredar de Collection.

El problema esta claro, tienes que tener el cuidado de hacer la llamada al método correcto. Si lo tuviese que hacer yo optaría por llamar a los métodos xxxxxxCondicionado de forma que me quedaría claro cuales son mis métodos (Pero esto es cuestión de gustos)

Espero te sirva,
un saludo,
kripton

[javimartinez]

Muchas gracias Kripton, pero con dicha solución el usuario seguiría pudiendo utilizar el método remove de la clase, cosa que quiero evitar.

Lo que quiero hacer es una clase como ArrayList (por eso la heredo), pero que antes de insertar o borrar elementos mire si se cumple una condición (que un atributo de MiArrayList sea cero) y, en caso de no cumplirse no dejar realizar la operación e indicarlo con una excepción. Por lo tanto, si creo un nuevo método (remove2) tendría que invalidar de alguna forma el anterior (remove), dejando de ser la clase tan atractiva para los futuros usuarios, ya que no tendría los mismos nombres de métodos que ArrayList.

¿A alguien se le ocurre otro solución?

Gracias y un saludo

[mariog]

lo que puedes hacer es que en la cabecera del método remove de la clase ArrayList, se lancen las mismas excepciones que en el remove de la clase que lo hereda.

Se supone que las cabeceras de los métodos que se sobreescriben deben ser iguales no?

[javimartinez]

Hola mariog!!!

Ese es precisamente el problema, que la cabecera tiene que ser exactamente igual y, por tanto, no puedo añadir mi propia excepcion. Lo que me gustaría hacer es lo siguiente:

---------------------
public tipo metodo(parametros) throws susExcepciones, MiNuevaExcepcion {
if (cond)
throws new MiNuevaCondicion();
else
return super.metodo();
}

----------------
Pero eso no se puede, y lo que estoy buscando es una alternativa que impida al usuario utilizar el método de la clase que se hereda y, por tanto, le obligue a utilizar el mio.


Gracias y un saludo

[mariog]

pero esq eso es imposible no?? a no ser q captures la excepcion dentro del método, debe ser lanzada, y para ser lanzad debes ponerlo en la cabecera, y por lo tanto si es diferente de la que hereda no t va a dejar.

[rebuscao]

A mi lo que se me ocurre es hacer que en la segunda solución que proponias se implemente la interfaz Collection.

Sludos.

[javimartinez]

Hola a tod@s

Gracias por vuestras soluciones, pero os comento:

>>mariog escribió: pero esq eso es imposible no??<<

Efectivamente, hasta donde yo se, esto es imposible, por lo que estoy buscando una alternativa que me permita realizarlo de alguna otra forma.

>>rebuscao escribió: A mi lo que se me ocurre es hacer que en la segunda solución que proponias se implemente la interfaz Collection.<<

En este caso se seguiría teneniendo el mismo problema, al implementar la interfaz Collection no podría añadir ninguna excepcion.

Estoy empezando a pensar que, como sugiere mariog, mi problema no tiene solución, y me tendré que implementar una solución que no cumpla con todos los requisitos.

Gracias y un saludo

[mariog]

Bueno, yo no se si esto que voy a decir es una tonteria o un poco lioso, pero igual sirve.
uando tu compruebas la condicion en el if, en vez de lanzar la excepción ahi directamente, puedes hacer que devuelva cualquier valor.
Luego al llamar al método en la ejecución, compruebas si te ha salido ese valor y si es así lanzas la excepción, así por lo menos la cabecera del método no la tienes porque cambiar, pero claro, eso depende ya mucho de como llames tu al método en la ejecución.
Ya se que es un poco rebuscado....

[josemi]

Hola,

Revisando mis casi olvidados conocimientos de Java y con la ayuda de TIJ, voy a dar un par de soluciones.

La primera es que si haces a tu excepcion derivada de runtimeexception, no tienes por que declararla en la cabecera de la funcion. La lanzas y ya esta. Aunque por lo que comentan por ahi, no es muy correcto desde el punto de vista purista.

La otra solucion es tirar una runtimeexception con tu excepcion como parametro. El problema que en este caso no podras hacer un catch directamente de tu excepcion, sino catchear la runtime y lanzar su parametro dentro de otro try y ahi si catchear tu execepcion. Esto lo he sacado del final del capitulo de exepciones del TIJ.

Espero haber sido de ayuda.