correction avant examens ce samedi

Salut à tous. J'ai besoin d'un petit coup de main car mon prof est aux abonnés absent. J'ai un exam sur java samedi. Je suis débutant et j'ai quelques erreurs sur des exercices (classes, classes avec héritage et exceptions). La réponse de mon prof m'a bcp surpris. Qq'un pourrait il m'aider et y jeter un oeil? helpppp :aie:

Salut,

On peut y jeter un coup d'œil bien sûr et t'aider si possible, mais il faut que tu nous montres (code, message d'erreur) et nous explique ce que ça doit faire, ce que ça fait ou ne fait pas...

merci joel
voici mes classes.
j'ai toujours le symbole "attention" qui apparait dans mes classes TitreException et NbPagesException
Mon prof me dit de ne pas mettre de t
"throws..." dans les classes héritant de Livre. Or si je ne le mets pas, une croix rouge apparait
Il me recommande de mettre 2 constructeurs dans ma classe NbPages Exception. Je ne vois pas comment
et surtout dans le PgPcl, quaand j'instancie un objet avec un paramètre négatif, géré par les exceptions, mon programme s'arrête.
Bref il m'a dit que tout été ok ...:?

Pour le message "attention", je suppose que tu parles du message qui dit qu'il n'y a pas "serialization number" ? Pas grave, c'est simplement qu'une Exception est forcément sérialisable, et que pour distinguer les version de classes, on les versionne en leur affectant un numéro. Si le numéro n'est pas explicitement mis, un sera affecté par défaut.
Tu peux ajouter private static final long serialVersionUID = 1L; dans tes classes d'exception pour éviter le warning.

Sinon ton prof t'aurait dit de ne pas mettre de throws dans les classes héritant de Livre. Je suppose que c'est valable aussi pour la classe Livre elle-même. Est-ce qu'on t'a demandé de gérer explicitement des exceptions ? Si oui, alors, pour éviter d'avoir à mettre un throws sur une méthode ou un constructeur, il suffit de faire hériter l'exception de RuntimeException au lieu de Exception.

Code:

---

1 2 3

public class NbPagesException extends RuntimeException { /*...*/ }

---

Pareil sur TitreException...

Et tu peux retirer le throws sur tous tes constructeurs.


PS. quand tu postes du code, c'est plus facile pour nous de le montrer entre balises CODE (avec le bouton # de l'éditeur), plutôt que de devoir les télécharger depuis des pièces jointes. Penses-y à l'avenir si tu reviens poser d'autres questions.

Ok merci pour ton aide. Mon code dans le cas de l'exam est d'après toi correct donc?

Pour la remarque au sujet des deux constructeurs de l'exception NbPagesException, c'est sûrement à cause de ça :

Code:

---

1 2 3 4 5

public NbPagesException(int nbPages){ super(); System.out.println("Instanciation d'un livre avec un nombre de pages négatif !"+nbPages);   }

---

et de ça :

Code:

---

1 2	if( cNbPages == 0){ throw new NbPagesException(cNbPages);}

---

Si le nombre de pages est 0, on aura comme message : "Instanciation d'un livre avec un nombre de pages négatif !0"

En dehors du fait que ce n'est pas très bien structuré (le chiffre collé au !, en dehors de la phrase), c'est très bizarre de dire que 0 est négatif !

Donc, je pense qu'il voulait dire de faire un constructeur spécial pour le nombre de pages à 0 :

Code:

---

1 2 3 4 5

public NbPagesException(){ super(); System.out.println("Instanciation d'un livre avec un nombre de pages nul !");   }

---

Personnellement, j'aurais fait un seul constructeur avec un if pour générer un message différent pour nbPages==0 et nbPages<0

En revanche je ne comprends pas ta phrase

Citation:

---

et surtout dans le PgPcl, quaand j'instancie un objet avec un paramètre négatif, géré par les exceptions, mon programme s'arrête.

---

a moins qu'il s'agisse du fait que ton programme n'est pas "fail fast" : en cas d'exception, il continue de s'exécuter, avec des données donc erronées. Sans throws dans tes constructeurs, plus besoin nécessairement de catch(), donc ton programme s'arrêtera à la première exception de lui-même. En plus, sans les catch, tu ne seras pas obligé d'affecter une valeur null bidon à tes variables. Au passage, pense au multicatch.



Ensuite, pour dire que le programme est correct, il va falloir que je le lise entièrement, et je n'ai pas vraiment le temps. Mais j'ai déjà vu quelques problèmes.

1. Déjà, je ne comprends pas cette histoire de méthode description() : c'est quelque chose qu'on t'a demandé ? Parce qu'il existe une méthode standard pour gérer la description (plus exactement la représentation sous forme de String / String representation). C'est la méthode toString(). Et ça évite d'avoir à écrire :
   
   Code:

   ---

   System.out.println(L1.description());

   ---

   car on peut écrire directement
   
   Code:

   ---

   System.out.println(L1);

   ---

2. Ensuite, on n'affiche pas de message dans le constructeur d'une exception, on affecte le message à l'attribut fait pour (par constructeur) :
   
   Code:

   ---

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

   public class NbPagesException extends RuntimeException { private static final long serialVersionUID = 1L; private final int nbPages;   public NbPagesException(int nbPages){ super(nbPages==0 ?"Instanciation d'un livre avec un nombre de pages null !" :"Instanciation d'un livre avec un nombre de pages négatif : "+nbPages+" !" ); this.nbPages=nbPages; }   public int getNbPages() { return nbPages; }   }

   ---

3. Pour afficher une stacktrace d'exception, on fait e.printStackTrace(); pas e.getStackTrace();, qui ne sert à rien. C'est d'ailleurs avec ce printStackTrace() que devient intéressant le fait que notre exception a un message (ce qu'on a fait au point 2) : il s'affiche à cet endroit et on peut comprendre quelle est l'erreur.
4. il y a un problème d'incohérence :
   changer le prix par le constructeur fait :
   
   Code:

   ---

   1 2	prix = cPrix; this.setCher();

   ---

   changer le prix par le mutateur fait :
   
   Code:

   ---

   1 2 3

   public void setPrix(int pPrix){ prix = pPrix; }

   ---

   Tu dois voir qu'il manque quelque chose, non ? Quelque chose qui va faire que ta variable cher ne sera pas forcément juste si on change le prix...
   

Pour le reste, il me faudra plus de temps pour regarder.

Autres choses tout de même : il y a des conventions en Java. Des conventions de nommage (lowerCamelCase pour les variables entre autres). Des conventions d'indentation aussi : c'est quoi cette nouvelle mode que je vois fleurir, avec l'accolade fermante derrière le point-virgule ? Comme ici :

Code:

---

1 2 3 4 5 6

try{ L1 = new Livre("Tout sur le CNAM", 120 );} catch (TitreException exc1){ exc1.getStackTrace(); }

---

C'est une volonté, après la mode de l'indentation à la C, de rendre le code moins lisible ?

Code:

---

1 2 3 4 5 6

try { L1 = new Livre("Tout sur le CNAM", 120); } catch (TitreException exc1) { exc1.printStackTrace(); }

---