Curso 2008/2009
Parte teórica
Parte práctica
Base de conocimiento (alias preguntas más frecuentes)
Parte teórica
Con el tema 10 finalizamos el estudio de los principios básicos de la programación orientada a
objetos: trataremos la herencia y el manejo de excepciones.
El tema de la herencia corresponde al apartado 5.7 del material que utilizamos. En este tema
se estudia la herencia y el polimorfismo. No os asustéis, se les dan nombres "extravagantes"
para que parezca algo difícil de entender. Pero con la base que tenéis de SGBD (de nuevo)
tenéis casi todo el camino recorrido.
No quiero complicaros con conceptos más "fuertes", así que el apartado 5.7.6 (interfaces) no
lo leáis. Sólo para el que le interese, comentar que es la manera que Java puede hacer
herencia múltiple, es decir, que una clase herede características de "varios padres".
NOTA:
Parte práctica
La décima Prueba de Evaluación Quincenal del módulo es una práctica dividida en dos partes.
1. La primera parte trata la herencia. Debéis crear dos nuevas clases que son heredadas
(extienden) la clase Equipo. Estas clases tienen atributos propios y sobrecargan el
método toString() para visualizar todos esos atributos.
Recordad que para acceder a la evaluación cuatrimestral, la entrega de todas las PEQs es
obligatoria (y cada una de ellas debe tener una nota superior a 2).
Base de conocimiento
De Anónimo:
Hola,
espere que anaren bé les vacances, continuant amb la feina, a la pràctica 10 hem de treballar amb les
excepcions, no estic molt segur quines excepcions por llançar aquesta aplicació, algun suggeriment?
O és suficient capturar totes les excepcions (Exception) i mostrar un missatge personalitzat per a cada
metode?
Salutacions
De Anónimo:
Per cert, és necessari controlar excepcions en els setters, que tan sols assignen una variable?
Doncs les vacances han anat molt bé, gràcies. Espere que a vosaltres també us haja anat bé.
Respecte el tema del treball amb les excepcions, heu de capturar totes les excepcions possibles. Pots
mostrar un missatge personalitzat o simplemet mostrar el missatge de l'excepció (en cas de que ja
estiga definida). En tot cas, hi ha dues variants d'excepcions que heu de controlar:
- Les excepcions que ja estan definides en els mètodes dels paquets dels quals feu ús. És a dir, en el
vostre cas, feu ús, per exemple, dels mètodes de la clase List. En cadascun d'aquests mètodes ja hi ha
definides excepcions que poden ocòrrer i són aquestes les que heu de controlar.
- Les excepcions pròpies del nostre problema. Aquestes apareixen per la semàntica de l'enunciat. Les
podeu comentar en un fil nou del fòrum per saber si es significatiu o no incloure una o una altra en el
codi. Per a mostra, us indicaré una: no pot existir un equip amb dos números de sèrie iguals. I, què
implica això? Això implica que en l'alta d'un equip o/i l'actualització del número de sèrie es llance una
excepció en cas que un altre equip tinga el mateix número de sèrie.
Salutacions,
Cristian.
De Anónimo:
Sí, ja està més clar.
De moment tinc les excepcions degudes a IndexOutofBounds de List, i vaig a crear un nou fil per a
discutir les possibles excepcions a llançar per la nostra aplicació.
Anónimo
Saludos,
Santi.
Gracias,
Santi.
Saludos,
Cristian.
De Anónimo:
Una proposta de possibles excepcions a llançar:
1. Si al comprovar que un numero de serie ja existeix al modificar o donar d'alta un equip es llança una
excepció.
Crec que aquestes dues són les més importants, però seria necessari controlar, per exemple que el
format de la data introduïda és correcta?
o altre referents al format de les variable, com per exemple, que CodigoServicio sols fora "secundaria,
cicles..."
Però les altres ja no ho són, fixa't que les altres dues ja no estan relacionades amb què interacció
(quines accions) realitza l'usuari, sinò de quina manera (com interactua) ho fa.
Això - una vegada més - s'ix dels objectius del mòdul. De totes maneres, si teniu interés, podeu
consultar-ho en Internet, en el que s'anomenen asercions.
Salutacions,
Cristian.
Saludos,
Santi.
1er apartado. Captura de las excepciones en las llamadas a métodos de la API. En este
apartado, simplemente has de comprobar qué llamadas haces en tu código a la API (p.e. a
métodos de List) que pueden devolver excepciones. Una vez las hayas encontrado, debes
capturarlas y mostrar un mensaje de error.
nuevo Equipo en el Inventario con el mismo número de serie, pero esto no debería suceder,
así que se debería ejecutar una excepción. Estas excepciones definidas por el usuario son las
que estamos comentando en este mismo hilo.
En tu pregunta sobre si se debe capturar (utilizar try) o crear la excepción, veo algo que no
debes haber entendido correctamente. Las excepciones que no existen, deben crearse
(apartado 2), pero aún así en algún momento – cuando sucedan - deberán capturarse (con
try). Por tanto, la creación y la captura no
son excluyentes, sino complementarias. En el caso de las excepciones que ya están creadas
(apartado 1) simplemente debes capturarlas (con try) por que otro programador ya ha hecho
el trabajo de creación por ti.
Respecto a la ampliación de material, deberías tener tener suficiente con mis comentarios del
blog y el material adicional que os propuse en su día (en concreto, curso de Java, apartado
7.3. Creación de excepciones de usuario). Allí tienes un ejemplo completo comentado. Si con
esto no tienes suficiente, dime qué dudas concretas tienes.
Un saludo,
Cristian.
Saludos,
Santi.
No entiendo qué quieres decir en la frase "cuando se pone una excepción", las excepciones o se
lanzan (throws) o se capturan (try/catch/finally), no se "ponen". Intedtad utilizar correctamente el
vocabulario técnico, porque si no ya sabéis que la comunicación se complica, y lo que es peor (en
especial para vosotros) se ralentiza.
De todas formas, intentaré explicarte algo con lo que he entendido. Si se cumple la condición, no
tienes que mandar ningún mensaje a la clase de la excepción, sino que la clase de la excepción habrá
lanzado una excepción y tú deberás controlar la recogida (capturar) esa excepción en tu código. Lo de
sacar un valor o no sacarlo no es importante, lo importante es que captures la excepción y muestres
un mensaje propio, en lugar del que te envia el JVM.
Un saludo,
Cristian.
Saludos,
Santi.
Creo que hay algo que te está confundiendo, pero no consigo saber exactamente qué es. Como
sé que es complicado haceros venir a las tutorías, te remito a otro ejemplo más práctico si cabe
que el de la documentación adicional, para ver si con esto lo entiendes. Lo tienes en esta
dirección:
http://www.cica.es/formacion/JavaTut/Cap6/crear.html
Esta es la última bala que me queda como recurso de explicación de las excepciones. Espero
que te sirva.
Un saludo,
Cristian.
Ho heu de comprovar amb el vostre codi. En cas que l'execució del mètode siga fallida, haureu de llançar
i/o capturar l'excepció.
Salutacions,
Cristian.
NOTA: Todos los comentarios tienen la autorización expresa de publicación de sus respectivos autores. Aquellos comentarios que aparecen firmados bajo la
autoría Anónimo, también se han publicado autorizados con la condición de no mostrar el nombre del autor.
Esta obra está bajo una licencia Reconocimiento-Compartir bajo la misma licencia 3.0 España de Creative Commons. Para ver una copia de
esta licencia, visite http://creativecommons.org/licenses/by-sa/3.0/es/ o envie una carta a Creative Commons, 171 Second Street, Suite
300, San Francisco, California 94105, USA.