Amis Zeros Bonjour !

J'aimerais afficher mon arbre binaire de recherche sous la forme suivante :
(10 - (8)(15- ()(26)))

Avec donc 10 comme racine, 8 et 15 les sous-arbres directs de la racine, () le sous arbre gauche vide de 15 et 26 le sous-arbre droit de 15 (je pense que vous aurez saisi ma logique d'affichage).

Pour cela j'ai donc créé un toString recursif qui appelle successivement donc les toString des sous-arbres gauches puis droits.
Cepandant, j'ai decidé d'attraper une exception pour afficher "()" en cas de sous-arbre vide avec NullPointerException.
Mais lorsque je fais cela, il n'execute plus les toStrings suivants !!

Je vous donne mon code de toString ainsi que l'affichage dans mon terminal.

public String toString(){
   String s="";		
   try{
      if(this.isLeaf()){ //Si l'abre est une feuille
         s=s+"("+this.getContent().toString()+")"; // On affiche donc juste la feuille par exemple "(10)"
      }else{
         s=s+"("+etiquette+"-"; //on affiche donc l'abre binaire à partir de la racine etiquette
         s=s+left.toString();
         s=s+right.toString();
         s=s+")";
      }
   }catch (NullPointerException e){
      s=s+"()"; // Si l'arbre ou le sous-arbre est vide je souleve l'exception et j'affiche "()"
   }
   return s;
}

Dans mon main je crée donc l'abre noeud apres noeud pour le test et j'essaye l'affichage :

public class Test{
   public static void main (String[] args){
      //Creation des noeuds 10, 8, 15
      MutableBinNodeImpl<Integer> noeud = new MutableBinNodeImpl<Integer>(10); 
      MutableBinNodeImpl<Integer> gauche = new MutableBinNodeImpl<Integer>(8);
      MutableBinNodeImpl<Integer> droit = new MutableBinNodeImpl<Integer>(15);
      
      noeud.setLeft(gauche); // 8 devient le sous arbre gauche de 10
      noeud.setRight(droit); //15 devient le sous arbre droit de 10

      // j'ajoute 26 en sous arbre droit de 15
      droit.setRight(new MutableBinNodeImpl<Integer>(26));
      
      //Je lance donc l'affichage de mon arbre a partir du noeud 10
      System.out.println("Noeud avec sous-arbres");
      System.out.println(noeud);
   } 
}

Et voilà le ce que j'obtiens à la fin !!!!

Noeud avec sous-arbres
(10-(8)(15-())

Je ne sais pas si j'ai été assez clair sur mon problème mais en gros j'obtiens à la fin dans ma console un arbre tronqué à partir du premier sous arbre vide. Etant donné que je capte ce cas dans mon try catch je voulais savoir en gros si c'était ce catch provoquait la sortie de ma boucle recursive...

Encore merci a tous !

Dans ton catch il appelle juste (dans l'implémentation de Sun) new StringBuffer(currentState).append("()");, y a aucun appel de la méthode toString de ton objet.

C'est vraiment pas très sur ton système, vaudrait mieux faire une méthode dédiée pour ça.

@shakhal Je vois pas le rapport avec le sujet

@dj-minoush
soit t'as même pas réfléchi soit tu ne sais pas du tout comment marche les exceptions. Forcement que si l'exception est levée sur left, bin tu vas jamais faire les lignes suivantes donc jamais faire s=s+right.toString();

Il existe un moyen très simple que s'appelle le if :
if(right==null){
//...
}else ...

Citation : Anarion9998

@shakhal Je vois pas le rapport avec le sujet

Ca a ete edite apres mon post, avec l'explication originale le probleme etait pas tres clair.

Anarion9998 a raison.
Ca manière de faire est beaucoup plus propre.
Il ne faut pratiquement jamais catcher les exceptions pour des petits projets.
Le catch sert, à mon avis uniquement, dans des programmes professionel pour ne pas avoir à relancer tout, lorsque c'est juste un developpeur qui s'est foiré sur son module.

Bon y a aussi les cas où les ressources sont inaccessibles (ouverture d'un fichier déjà bloqué).
Mais bon une erreur en local et le développeur comprends vite qu'il doit fermer, plutôt que d'avoir un message d'erreur fait maison

Citation : matouse

Le catch sert, à mon avis uniquement, dans des programmes professionel pour ne pas avoir à relancer tout, lorsque c'est juste un developpeur qui s'est foiré sur son module.

Eventuellement pour faire des rollbacks quand même.

C'est vrai que je ne pensais pas aux base de données, mais ca reste pour moi à priori dans le cadre de projet professionel.
L'utilisation de rollback ne fait normalement pas parti de petit projet.
En tout cas je ne connais pas de projets qui en ont eu besoin mais peut être que j'utilise mal les rollback :).
Pour un moi un rollback sert uniquement lors d'une panne, et je n'ai jamais vu de petit projet cherchant une telle tolérance aux pannes

Citation : matouse

Le catch sert, à mon avis uniquement, dans des programmes professionel pour ne pas avoir à relancer tout, lorsque c'est juste un developpeur qui s'est foiré sur son module.

Bon y a aussi les cas où les ressources sont inaccessibles (ouverture d'un fichier déjà bloqué).
Mais bon une erreur en local et le développeur comprends vite qu'il doit fermer, plutôt que d'avoir un message d'erreur fait maison

Pas du tout, les exceptions sont un puissant mécanisme pour corriger un comportement non attendu, par exemple:

public Color(final String color) {
        this();
        try {
            String[] s = color.split(",");
            this.red = this.checkValue(Integer.valueOf(s[0]));
            this.green = this.checkValue(Integer.valueOf(s[1]));
            this.blue = this.checkValue(Integer.valueOf(s[2]));
        } catch (NumberFormatException e) {
            throw new ObjectInitializationException(
                    "The constructor String parameter is not valid.");
        }
    }

Dans ce cas me message(reçu par le réseau) n'est pas conforme à la synthaxe attendue.

protected final void checkMutability() {
        if (this.immutable) {
            throw new ImmutableClassException();
        }
    }

public final void setValue(final double angleValue) {
        this.checkMutability();
        this.value = angleValue;
    }

Ici on lance une exception si quelqu'un essaie de modifier un objet qui doit être immutable.

public SocketWrapper connect(final String host, final int port) {
        try {
            Socket s  = new Socket(host, port);
            return this.connect(s);
        } catch (UnknownHostException e) {
            throw new NetworkHostException(e);
        } catch (IOException e) {
            throw new NetworkException("Error creating socket", e);
        }
    }

et dans ce cas ci, la machine distante à contacter est inaccessible.

Bref, on peut se servir tout le temps des exceptions.



edit:

Citation

L'utilisation de rollback ne fait normalement pas parti de petit projet.
En tout cas je ne connais pas de projets qui en ont eu besoin mais peut être que j'utilise mal les rollback :).
Pour un moi un rollback sert uniquement lors d'une panne, et je n'ai jamais vu de petit projet cherchant une telle tolérance aux pannes

Le rollback est utile même sur un petit projet à partir du moment ou on a des transaction qui vont se dérouler en plusieurs étapes et qui sont liés:

-UPDATE tableA SET truc = 5 WHERE machin < 10;
-UPDATE tableB set bidule = 'blabla';
si le 2e update plante(une exception dans le code java appelant par exemple), la 1ere doit subir un rollback pour garder la cohérence des données.

Justement je ne suis pas vraiment d'accord avec ton utilisation
D'un tu catch des exceptions pour mettre des messages à toi, fait maison, mais il ne seront jamais aussi précis qu'une exception qui te permettra d'avoir un lien faire la ligne qui a planté et une trace d'execution.
Et puis tu triches un peu tout tes exemples catch une exception pour en lever une autre

Quand au rollback, la seule chose ou je pourrais comprendre serait une histoire d'intégrité référentielle.
Je ne sais pas comment java gère les contraintes d'intégrité avec les foreign key par exemples.
Là okai il faut garantir le principe des transactions.
Je suis étonné qu'il n'y ai pas des API pour ça (comment ça je suis persuadé du contraire, mais j'ai pas cherché )

Citation : matouse

Justement je ne suis pas vraiment d'accord avec ton utilisation
D'un tu catch des exceptions pour mettre des messages à toi, fait maison, mais il ne seront jamais aussi précis qu'une exception qui te permettra d'avoir un lien faire la ligne qui a planté et une trace d'execution.

catch (NumberFormatException e) {
throw new ObjectInitializationException(
"The constructor String parameter is not valid.");

Dans ce cas, il est plus clair de savoir qu'on a eu une erreur d'initialisation suite a une string invalide plutot qu'une exception sur un nombre mal parsé

if (this.immutable) {
throw new ImmutableClassException();
}

Ici, l'exception parle d'elle même, pas besoin de message.

catch (UnknownHostException e) {
throw new NetworkHostException(e);
} catch (IOException e) {
throw new NetworkException("Error creating socket", e);
}

enfin ici, seul cas dans ceux présenté ou il est pertinent d'avoir le message d'origine, le reste du stack est récupéré(et journalisé par l'exception personnalisée).

Citation : matouse

Et puis tu triches un peu tout tes exemples catch une exception pour en lever une autre

le rethrow d'exception check vers des unchecked est une pratique courante pour récupérer le message d'erreur dans la vue.

Citation : matouse

Quand au rollback, la seule chose ou je pourrais comprendre serait une histoire d'intégrité référentielle.
Je ne sais pas comment java gère les contraintes d'intégrité avec les foreign key par exemples.
Là okai il faut garantir le principe des transactions.
Je suis étonné qu'il n'y ai pas des API pour ça (comment ça je suis persuadé du contraire, mais j'ai pas cherché )

une exemple tout simple: virement banquaire de mr X à mr Y:
UPDATE account SET amount = amount - 10 WHERE name = 'mr X';
UPDATE account SET amount = amount + 10 WHERE name = 'mr Y';
si la 2e transaction plante, il est évident que mr X doit récupérer ses 10€, d'où une nécessité de faire un rollback.

C'est le principe même de la transaction, et comme shakhal l'a fait remarqué et comme le nom n'est pas si mal trouvé que cela, l'exemple type est une transaction bancaire. Pour ce qui est des frameworks, tous ceux implémentent la notion de transaction utilisent bien entendu la notion de rollback. (Hibernate par exemple).

Les exemples que shakhal t'a donnés sont très pertinents mais ne sont pas exhaustifs évidemment. La gestion correcte des exceptions est très subtile et dire que "cela ne sert à rien dans des petits projets" c'est prendre un raccourci hasardeux. Il faut bien penser qu'en outre tu peux définir tes propres exceptions avec des attributs, celles-ci pouvant être éventuellement rattrapées pour réagir "en conséquence" en fonction de ces attributs, c'est quand même un mécanisme intéressant à ne pas négliger.

Un mail n'a pas pu être envoyé par l'application car la connexion réseau est introuvable et/ou le serveur smtp est injoignable, sachant que je gère une centrale nucléaire, je rattrape l'exception ou je laisse le soft planter ? L'exemple est volontairement débile mais l'idée est bien là. C'est véritablement du cas par cas, et même un zér0 devrait dans l'idéal toujours se poser la question plutôt que de rattraper toutes les exceptions ou, dans l'excès inverse, tout balancer en Runtime. Ou tout au moins en être averti.

Yop yop, on a du mal à se comprend, j'ai l'impression
Je sais bien que les try catch peuvent servir
Je ne suis pas d'accord avec shakhal sur l'utilisation qu'il en fait en terme de dev.
Le fait de catcher une exception pour en relancer une d'un autre type, c'est typiquement associé à un programme pro.
Les messages fait maison seront toujours moins précis que ceux de la JVM, par contre, ils seront plus lisible pour un client du genre écrit en français.
Mais là encore je parle bien de client.

Pour moi une exception d'un type tu la laisses remonter si tu veux la voir, sinon tu la catch et dans ce cas c'est que tu fais de la tolérance au panne.

Dans le cas de transaction un rollback correspond également à une tolérance au panne
Tolérance au panne = sujet pro ,
@ Javier : si lorsque tu utilises ton appli, t'as le courant qui pete, t'en as un peu rien à faire de ta transaction
si tu gères un central nucléaire bien évidemment, tu fais du pro et pas de la bidouille

Vous le dites vous même je fais 2 requêtes, la deuxieme plante et ben dans ce cas tant pis.
Mon appli perso ne fait pas de tolérance au panne point
Je ne développe pas un vrai systeme bancaire non?

Juste pour appuyer ce que je dit:
http://www.siteduzero.com/forum-83-500 [...] e-thread.html
voilà exactement comment la plupart des débutant utilisent les try catch et voila pourquoi j'en déconseille leur utilisation

Citation

dans des petits projets

.

Citation : matouse

Yop yop, on a du mal à se comprend, j'ai l'impression
Je sais bien que les try catch peuvent servir
Je ne suis pas d'accord avec shakhal sur l'utilisation qu'il en fait en terme de dev.
Le fait de catcher une exception pour en relancer une d'un autre type, c'est typiquement associé à un programme pro.

Du tout, le rethrow par unchecked est juste associé à la séparatation de la vue et de la logique, afin de la faire remonter jusque la vue, rien à voir avec le monde professionnel, juste une bonne pratique reconnue.

Citation : matouse

Les messages fait maison seront toujours moins précis que ceux de la JVM, par contre, ils seront plus lisible pour un client du genre écrit en français.
Mais là encore je parle bien de client.

Quand tu te prends une NPE et que tu dois remonter de x classes dans le stack parce qu'un truc s'est mal déroulé avant, je t'assure que tu aurais préferé lancer une exception perso là ou ça s'est vraiment mal placé.

Citation : matouse

Pour moi une exception d'un type tu la laisses remonter si tu veux la voir, sinon tu la catch et dans ce cas c'est que tu fais de la tolérance au panne.

Une exception n'est pas une panne, c'est un comportement attendu mais exceptionnel comme son nom l'indique(mais une exception peut aussi résulter d'un mauvais comportement du système c'est évident).

Citation : matouse

Dans le cas de transaction un rollback correspond également à une tolérance au panne
Tolérance au panne = sujet pro ,
@ Javier : si lorsque tu utilises ton appli, t'as le courant qui pete, t'en as un peu rien à faire de ta transaction
si tu gères un central nucléaire bien évidemment, tu fais du pro et pas de la bidouille

Donc d'après toi tous les projets non professionels doivent être codé n'importe comment? et pour mon projet perso qui fait actuellement +/- 20000 lignes je fais quoi? je me dit que si ça plante c'est pas grave vu que c'est pas pro?

Citation : matouse

Vous le dites vous même je fais 2 requêtes, la deuxieme plante et ben dans ce cas tant pis.
Mon appli perso ne fait pas de tolérance au panne point
Je ne développe pas un vrai systeme bancaire non?

le rapport? la DB n'a pas besoin de données intègres parce que c'est pas un système bancaire?

Citation : matouse

Juste pour appuyer ce que je dit:
http://www.siteduzero.com/forum-83-500 [...] e-thread.html
voilà exactement comment la plupart des débutant utilisent les try catch et voila pourquoi j'en déconseille leur utilisation

Citation

dans des petits projets

.

Son utilisation des threads est mauvaise, son utilisation des sockets est mauvaises, sa découpe des responsabilités est mauvaise, donc si on fait comme tu dis il pourrait plus rien utiliser.
J'ai commencé comme ça, en mettant des catch pour que le compilo me fiche la paix, et ça m'empêché pas de m'être rendu compte qu'il y avait moyen de mettre des choses plus utiles que e.printstacktrace() au bout d'un moment, on s'améliore en praticant et donc pour s'améliorer dans l'utilisation des exceptions, il doit les utiliser.
Tout le monde fait du code moche en débutant.

Pour résumer grossièrement mon avis (et ça doit rejoindre à peu près celui shakhal si je l'ai bien compris) c'est pas parce que tu fais un "petit projet" que tu ne dois pas au moins être sensibilisé au fait qu'il y a un mécanisme de gestion des Exceptions dans java, qu'il y a des moyens propres et utiles de s'en servir. Dire "ça sert à rien pour les ptits projets" je me répète, c'est trop réducteur et source de confusion. Autant se servir de "petits projets" pour coder comme il faut et appréhender des mécanismes (parfois) avancés.

Bonjour
@javier
Qu'appelles-tu sensibiliser?
Savoir que ça existe et pas savoir comment ça marche?
C'est encore pire que de savoir s'en servir correctement
Je disais seulement, la plupart du temps, les personnes les utilisent mal, exactement comme dans mon exemple.
Lorsqu'on en a besoin explicitement (transaction, disponibilités de ressources, etc..), on s'en rend compte et on se renseigne dessus
De mon expérience, j'ai vu beaucoup de mauvais code sur les exceptions, donc je les déconseille.
J'ai même eu la chance d'avoir un débutant qui m'offrait un exemple
Je remercie ashura

Au passage je ne crois pas que ce soit le sujet de ce topic, c'est plus un problème de conviction basé sur nos expériences, ca peut durer longtemps, j'ai peur.
N'ayant pas vraiment plus d'arguments que les exemples que je vois.

"Autant se servir de "petits projets" pour coder comme il faut et appréhender des mécanismes (parfois) avancés"
Argh encore un sujet qui peut durer
Oui et non dépend de la finalité, coder pour apprendre, par intêret personnel oui,
coder sous contrainte, projet scolaire à rendre non
(bien sur, tout dépend pour chacun de l'interet d'un projet scolaire, mais moi ca me faisait carrément chié, quel interêt à coder un truc que tout le monde code et qui sera jamais utilisé?...
celui qui me répond pour apprendre, je le passe par la fenêtre )

@shakhal
s'il te plait arrête de me citer et de découper mon texte pour me répondre
Ca devient illisible à force, je t'assure je me rappelle de ce que je dis et surtout on est toujours dans la même discussion, la même page etc..
merci
pour te répondre :
quand je prends un NPE, j'ai d'un, que 3 ou 4 classes à remonter -> petit projet
et surtout deuxièmement non ca me derange pas de remonter x classes, eclipse me fait ça très bien. Au contraire je vois le chemin de l'appelle

Pour le rapport entre panne et exception :
J'aime bien " comportement attendu mais exceptionnel "
Je ne sais pas si tu essayes de faire un lien entre Throwable et Exception mais dans ce cas je t'arrête de suite.
Peux-tu me donner un exemple d'une exception qui ne provient pas d'une panne, un problème?
Je suis d'accord sur ta définition d'exception. Je n'ai jamais dit qu'une panne, un problème ne pouvait pas être prévisible
exemple: je peux prédire que si ma bdd est lock, mon programme va merder je mets une exception pour avoir un message en francais et je rethrows l'exception.


"20000 lignes je fais quoi? je me dit que si ça plante c'est pas grave vu que c'est pas pro"
=>
oui
je rigole
si tu es assez barge pour te faire 20.000 lignes, tu seras quand même bien d'accord que tu ne fais plus partie de ma catégorie "petit projet" non?
de même pour la BDD, dans ma vision du petit projet, tu checke la BDD à la main donc oui, c'est pas grave d'avoir des incohérence, tu les corriges ensuite

merci d'avoir lu

voila un comportement attendu mais exeptionnel:

@Override
    public void run() {
        //TODO add timer.getTotalTime and remove entityToBuildType.
        long totalTime = this.entityToBuildType.getTimeToBuild();
        while (!timer.isTimeElapsed()) {
            try {
                Thread.sleep(100);
                this.builder.updateBuildingStatus(timer.getElapsedTime(),
                        totalTime);
                this.listener.buildingStatusUpdated(this.builder);
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            } catch (ArithmeticException e) {
                //FIXME remove this
                // divide by 0, nothing to do but but waiting the next pass
            }
        }
        this.builder.setBuildingStatus(0f);
        this.listener.buildFinished(this.builder);
    }

au premier passage on se prend une division par zero, alors oui c'est évitable(et le code est moche) mais ça fait partie des cas qui peuvent arriver sans porter conséquence au déroulement de l'application.


un autre:

try {
    this.root.initialise(false, "", "");
} catch (NullPointerException e) {
    // its ok to get a null pointer exception here
    // ogre does not create a new IRenderWindow

C'est un comportement normal venant d'une librairie externe, aucun soucis encore une fois.

enfin un dernier:

try {
    int id = this.graphicEngine.throwRay(cursorPosition);
    Entity selectedEntity = EntityManager.getInstance().getEntityFromId(id);

    this.selectionManager.addSelection(selectedEntity, true);
    this.gui.updateSelection(this.selectionManager.getSelectionList());

 } catch (NoSelectionException nse) {
    this.selectionManager.clearSelection();
    this.gui.updateSelection(null);
}

pas très élégant j'avoue(d'ailleurs ça va disparaitre au profit du polymorphisme sur les entity) cependant l'idée est bien là, je clic dans le vide, ça balance une exception qui dit que rien n'est sélectionné, parce que théoriquement, on clic pas dans le vide(dans ce cas c'est surtout pour éviter les traitements inutiles en passant directement dans le catch et en ignorant les méthodes entre l'appelant et le receveur).


donc exception != panne.

Juste un truc ca :

catch (InterruptedException e) {
Thread.currentThread().interrupt();//ne sert à rien
}

Si tu as une InterruptedException, le thread a déjà été interrupt donc ca sert à rien d'appeler cette méthode.

Citation : Anarion9998

Juste un truc ca :

catch (InterruptedException e) {
Thread.currentThread().interrupt();//ne sert à rien
}

Si tu as une InterruptedException, le thread a déjà été interrupt donc ca sert à rien d'appeler cette méthode.

http://www.ibm.com/developerworks/java [...] jtp05236.html

C'est bien ce que je dis normalement si tu mets ton catch là ou il faut pas besoin de faire ca, car tu traitre l'interruption dans le catch. Inutile de mettre ce genre de code sauf si on s'en sert vraiment, ce qui n'est pas le cas dans ton exemple, ni dans la grande majorité des cas où ton thread ne sera pas managé par autre chose, surtout que tu risque une boucle infinie suivant ce que tu fais, car ca va réinterrompre le thread au prochain sleep ce qui n'est pas forcement voulu.

edit : exemple

class t{
  public static void main(String [] args){
    t2 t2=new t2();
    t2.start();


    try{
      Thread.sleep(100);
      t2.interrupt();
      t2.join();
    }catch(InterruptedException e){
    }

  }
}

class t2 extends Thread{

  public void run(){
    while(true){
      try{
        Thread.sleep(10000);
        return;
      }catch(InterruptedException e){
         System.out.println("titi");
         Thread.currentThread().interrupt();
      }
    }
  }
}

il est mal placé en effet, merci, c'est en sortie de boucle qu'il doit être appelé pour une tache non interruptible.

pour la boucle infinie cependant, y a pas de soucis dans mon code vu qu'elle est basée sur un temps:

while (!timer.isTimeElapsed())
(chaque appel de la méthode met a jour le temps courant)

encore merci pour ta remarque.

Citation : Anarion9998

@shakhal Je vois pas le rapport avec le sujet

@dj-minoush
soit t'as même pas réfléchi soit tu ne sais pas du tout comment marche les exceptions. Forcement que si l'exception est levée sur left, bin tu vas jamais faire les lignes suivantes donc jamais faire s=s+right.toString();

Il existe un moyen très simple que s'appelle le if :
if(right==null){
//...
}else ...

OUAIS OUAIS OUAIS !
Heu jme sens un petit peu bête là ouais!
En fait oui c'était exactement cela je ne comprenais pas bien le mécanisme de l'exception donc j'ai evidemment réécrit le programme avec des if==null etc!
Merci bcp!