Class Pile, exceptions

"j'ai une erreur aux lignes ou j'empile"
Ce n'est pas normal, ta pile doit être extensible autant que nécessaire.

"comment faire pour faire un autre try ?"
Je ne vois pas pourquoi tu aurais besoin d'un autre try, mais tu peux les imbriquer comme n'importe quelle autre structure conditionnelle.

try
{
    try
    {
    }
    catch ()
    {
    }
}
catch ()
{
    try
    {
    }
    catch ()
    {
    }
}

Je ne vois toujours pas où est le problème...

Tu pourrais faire :

try
{
    while (true)
        pile.empiler(new Object()); 
}
catch (PilePleineException e)
{ 
    e.printStackTrace();
    System.exit(1);
}

ou encore :

while (true)
{
    try
    {
        pile.empiler(new Object()); 
    }
    catch (PilePleineException e)
    { 
        e.printStackTrace();
        System.exit(1);
    }
}

Mais il n'y a qu'un seul try, pas deux... Et j'insiste, l'exception PilePleine ne devrait pas exister !

Désolé , mon msg arrive en retard,

C'est ce qu'expliquait tksteph :

Puisque tu attrapes les Exceptions de type PileVide et PilePleine, Il faut que dans ta classe pile que les méthodes empiler(Object o){} et depiler(){} popagent ces exceptions (Sinon il ne sert à rien de les attraper à l'exterieur)

Si tu n'as jamais d'erreur de type PilePleine (ce qui devrait être le cas), inutile de faire un try/catch dessus, et plus qu'être inutile c'est faux de faire un try/catch pour rien...

on a bien un maxPile :) merci

J'ai corrigé le programme en faisant respectivement p et v.toString... cela suffit il ?

ça peut se faire,
Mais t'as quoi comme résultat après tes tests.

NB: Il est bien de penser à tes tests à chaque fois que tu ecris tes codes:

Comment vais-je appeller tels classe? méthode?...
Quel résultat dois-je attendre..

Celà te permet de faire un code "propre" et sympa

Normalement, tu ne devrais pas surcharger la méthode toString des Exceptions sauf dans de très rares cas où elles possèdent des attributs, ce qui n'est pas ton cas.

La bonne manière de faire est d'appeler le super constructeur Exception(String message), voir même Exception(String message,Throwable cause), au cas où l'exception est dû à une autre exception que tu as géré.

public class PileVide extends Exception
{
    public PileVide()
    {
        super("La pile est vide");
    }
}

public class PilePleine extends Exception
{
    public PilePleine(int max, Object obj)
    {
        super("Pile pleine, taille:"+max+",objet non ajouté:"+obj);
    }
}

"class Pile extends Vector"

Si ta classe étend Vector, alors c'est un tableau, voire une liste, mais pas une pile !

if (this.isEmpty()) { 
return true; 
} 
else { 
return false; 
} 

Ce genre de test est absurde, this.isEmpty est déjà un booléen, tu peux le renvoyer immédiatement, mais la méthode complete est absurde, pourquoi aller utiliser la méthode pileVide (qui est private !!) alors que la classe Vector nous laisse déjà à disposition la méthode isEmpty qui est public...

ps. this.size()>maxPile est faux, ici tu as un max=10, ça veut dire que tu ne détecteras l'exception que la taille sera 11, alors que tu n'aurais jamais du mettre ce onzième élément !

Bref, je ne vais pas faire toutes les lignes, je l'ai déjà dit hier, ce que tu fais n'est pas une pile.

Je reviens juste sur les Exception, à croire que je parle dans le vide, on ne doit pas redéfinir la méthode toString d'une exception, elles ont un format standardisé qui s'héritent grâce à leur constructeur, tu ne peux pas mettre ce que tu veux, sinon ça brise l'intérêt des exceptions.
De plus conserver l'objet qui est en trop dans la pile est inutile, c'est la pile qui a planté, ce n'est pas la faute de cet objet, donc le stocker n'a aucun intérêt si ce n'est pour ton toString que tu ne devrais pas faire, alors que je t'ai montré comment faire sans !

On a corrigé ca comme ca en cours pour les exceptins au fait :s, et l'enoncé est un TP:s.