Aide Java pour débutant - Page 4

Pen^2 (./68) :

iwannabeamaki (./66) :
Tu as un exemple ?

De ? D'exception en attribut ?
Ben, pas spécifiquement là tout de suite, mais ça prendrait trente seconde à coder. Tu veux que je teste les perfs ? Je sais pas si j'aurai le courage ce soir

Bon, voici le code de test, puis les résultats :

/**
 *
 */


package exceptions_test ;


public class Main
{
   public int methodReturnInt( String param )
   {
      if ( param == null ) {
         return -1 ;
      }
      // traitement
      return 0 ;
   }





   public void methodThrowsException( String param )
         throws Exception
   {
      if ( param == null ) {
         throw new Exception("La valeur 'null' n'est pas acceptée") ;
      }
      // traitement
   }





   private static final Exception e= new Exception("La valeur 'null' n'est pas acceptée") ;
   public void methodThrowsStaticException( String param )
         throws Exception
   {
      if ( param == null ) {
         throw e ;
      }
      // traitement
   }












   public void testPerf( String param, int iteration )
   {
      long start ;
      long duree ;

      System.out.println(" * " + iteration + " appels de methode avec '"+ param + "': ") ;


      System.out.print("\t methodReturnInt        : ") ;
      start= System.currentTimeMillis() ;
      for ( int i= 0 ; i < iteration ; i++ ) {
         switch ( methodReturnInt(param) ) {
            case -1:
               // Traitement Erreur
               break ;
            case 0:
               // Traitement OK
               break ;
         }
      }
      duree= System.currentTimeMillis() - start ;
      System.out.println(duree + " ms.") ;



      System.out.print("\t methodThrowsException  : ") ;
      start= System.currentTimeMillis() ;
      for ( int i= 0 ; i < iteration ; i++ ) {
         try {
            methodThrowsException(param) ;
            // Traitement OK
         }
         catch ( Exception e ) {
            // Traitement Erreur
         }
      }
      duree= System.currentTimeMillis() - start ;
      System.out.println(duree + " ms.") ;




      System.out.print("\t methodThrowsStaticException  : ") ;
      start= System.currentTimeMillis() ;
      for ( int i= 0 ; i < iteration ; i++ ) {
         try {
            methodThrowsStaticException(param) ;
            // Traitement OK
         }
         catch ( Exception e ) {
            // Traitement Erreur
         }
      }
      duree= System.currentTimeMillis() - start ;
      System.out.println(duree + " ms.") ;
      System.out.println() ;
   }





   /**
    * @param args
    */
   public static void main( String[] args )
   {
      Main obj= new Main() ;

      int iteration= 5000000 ;

      obj.testPerf("string", iteration) ;
      obj.testPerf(null, iteration) ;
   }

}

 * 5000000 appels de methode avec 'string': 
	 methodReturnInt        : 19 ms.
	 methodThrowsException  : 10 ms.
	 methodThrowsStaticException  : 8 ms.

 * 5000000 appels de methode avec 'null': 
	 methodReturnInt        : 9 ms.
	 methodThrowsException  : 4739 ms.
	 methodThrowsStaticException  : 700 ms.

Alors, OK, c'est plus lent, mais déjà que pour le test c'est pas dramatique.... Et quand on voit tous les avantages d'une Exception par rapport à un code d'erreur moisi...

A mon avis, le Integer.parseInt n'utilise pas une exception statique, donc ton test est un peu biaisé ^^ et en pratique pas grand monde n'utilise d'exception statique donc bon...

cross

PS : Vous noterez au passage que dans le cas normal (pas d'Exception retournée), la méthode qui génère une static Exception est plus de deux fois plus rapide (je suppose que c'est dû au fait qu'elle ne retourne rien)

Bref, si on résume, avec une Exception et quand on sait coder un minimum, c'est plutôt plus rapide... Et si on se rappelle que là on a des fonctions vides, l'influence des Exceptions est quasi nul, en fait...
Bref.

Brunni (./92) :
et en pratique pas grand monde n'utilise d'exception statique donc bon...

Donc bon, quoi ? Allouer des trucs sans raison est une mauvaise idée, c'est tout. Ça fait partie des trucs qui renseignent sur la qualité du codeur, comme tu le disais un peu plus haut. Perso quand je vois des trucs du genre de

 if ( !new File("huhu").exitst() ) {
   new File("huhu").doSomething() ;
}

je prends peur

Tu n'as qu'à allouer 500000000 de trucs en C++, je serais étonné que ça fonctionne super bien.. .Et j'ai beau ne pas m'y connaître outre mesure en C++, il me semble que les copies cachées (=allocations) sont une des choses qui grèvent les performances.

Pen^2 (./93) :
quand on sait coder un minimum

Savoir coder?

Il existe une contradiction entre les faits et la déclaration du témoin votre honneur!
Présenter: le titre du topic (.contains("JAVA"))

Pen^2 (./90) :

(en fait je fais de l'*informatique scientifique* )

Ouaaaah, c'est classe !

./93 :

On est d'accord : l'exception est une bonne idée quand elle reste exceptionnelle (ça semble plutôt logique, ça tombe bien ^^). En revanche, si on prévoit que la proportion d'appels qui génère une exception n'est pas négligeable, vu que c'est quand même presque 100 fois plus lent même avec ton astuce d'exception statique, il vaut mieux choisir une autre méthode.

Accessoirement, comme le "methodThrowsStaticException" réutilise toujours la même exception, on a pas de moyen efficace pour y placer un message personnalisé en fonction du contexte où s'est produite l'exception (genre "la valeur 3 est invalide" au lieu de "valeur invalide"), ce qui limite déjà pas mal l'intérêt d'une exception.

Pen^2 (./94) :
Et j'ai beau ne pas m'y connaître outre mesure en C++, il me semble que les copies cachées (=allocations) sont une des choses qui grèvent les performances.

Théoriquement les copies cachées d'objets conséquents ne réallouent pas les données, elles se contentent de pointer dessus jusqu'à ce qu'on décide d'utiliser la nouvelle instance en écriture, et c'est à ce moment seulement que les données sont dupliquées en mémoire. Il me semble que la STL fonctionne comme ça, à moins que ce ne soit seulement les types proposés par Qt ?

(en tout cas ça reste une bonne pratique de faire comme ça quand on implémente une classe qui utilise des ressources, puisque ça limite beaucoup l'impact des multiples copies d'objet qui ne servent qu'en lecture)

Brunni (./95) :

Pen^2 (./93) :
quand on sait coder un minimum

Savoir coder? En parlant de Java? Ca mérite une

C'est pas de ma faute si on ne me laisse pas coder en 68k

Nil (./96) :

Pen^2 (./90) :

(en fait je fais de l'*informatique scientifique* )

Ouaaaah, c'est classe !

triclasse, surtout \o/

iwannabeamaki (./97) :
./93 :

On est d'accord : l'exception est une bonne idée quand elle reste exceptionnelle (ça semble plutôt logique, ça tombe bien ^^). En revanche, si on prévoit que la proportion d'appels qui génère une exception n'est pas négligeable, vu que c'est quand même presque 100 fois plus lent même avec ton astuce d'exception statique, il vaut mieux choisir une autre méthode.

Pour du code uber critique, sans doute, mais bon... Ça ne doit pas arriver très souvent.

Accessoirement, comme le "methodThrowsStaticException" réutilise toujours la même exception, on a pas de moyen efficace pour y placer un message personnalisé en fonction du contexte où s'est produite l'exception (genre "la valeur 3 est invalide" au lieu de "valeur invalide"), ce qui limite déjà pas mal l'intérêt d'une exception.

Ben si, tu peux très bien instancier autant d'exceptions que tu aurais codé de codes d'erreur différents, ça ne change rien.

iwannabeamaki (./97) :
Théoriquement les copies cachées d'objets conséquents ne réallouent pas les données, elles se contentent de pointer dessus jusqu'à ce qu'on décide d'utiliser la nouvelle instance en écriture, et c'est à ce moment seulement que les données sont dupliquées en mémoire. Il me semble que la STL fonctionne comme ça, à moins que ce ne soit seulement les types proposés par Qt ?

Ah, OK, intéressant. Merci.

Ah c'est pratique, quand tu veux faire apparaître la valeur de ton int dans ton exception, tu en instancies INT_MAX au lancement pour être sûr d'avoir ce qu'il te faut ?

(et c'est encore plus drôle si tu veux afficher un message du style "le fichier plop.jpg est introuvable" )

iwannabeamaki (./102) :
tu en instancies INT_MAX au lancement pour être sûr d'avoir ce qu'il te faut ?

Exactement


OK, OK. Je comparais juste ça avec la technique des codes d'erreurs

pour info les CB et les SIM sont codées en java. ce sont des systèmes avec ~1k de RAM et 32-256k de flash.

mais on n'a pas intéret à coder avec les pieds: new truc() enregistre l'objet en flash, pas en RAM. Du coup vaut mieux réfléchir avant de créer des objets

du coup toutes les exceptions javacard sont statiques

-

Plus sérieusement, on peut coder bien en Java (après tout) mais ce n'est pas ce qu'on enseigne couramment. Tout le monde croit savoir faire du Java, même ceux qui l'ont appris rapidement sur le tas, et aussi ce qu'on trouve sur le net est souvent moche.
Dans le cas du parseInt ce n'est pas qu'une question de performance (on ne peut pas influencer ce que la routine fait en interne, donc discuter de ces bidouilles pour rendre la solution moins mauvaise n'est pas vraiment utile et ne signifie PAS savoir coder) c'est plutôt qu'il y a plusieurs cas:
* Soit le fait que ce soit effectivement un entier est obligatoire à la suite du programme (typiquement dans un compilo: integer token expected here ou sinon je plante et je quitte), dans ce cas lancer une exception est justifié,
* Soit on aimerait bien que ce soit un entier, mais ce n'est pas fatal (typiquement on va mettre un message en rouge devant le champ), et à ce moment-là c'est une mauvaise solution. Certains la résoudront avec une suite de try catch mais ça ne cause que des problèmes et c'est moche. Le problème vient du fait que si on fait un try catch sur toute la validation du formulaire, il n'y a pas moyen d'indiquer spécifiquement ce qui s'est mal passé. C'est pour ça que le modèle est mauvais.
En attendant la solution la moins pire est d'utiliser une regexp (ou au pire de wrapper les try catch dans des validateurs mais ), mais il y a de quoi se taper la tête contre les murs.

Brunni (./64) :
Comble: les codeurs java ont souvent si peu de considération pour les perfs que leurs progs arrivent à leaker malgré le GC (GWT dev mode, Eclipse, glassfish, etc.)

Bah c'est pire que ça : le GC est fondamentalement un leak plus ou moins contrôlé... ça revient à utiliser des seaux percés, et quand on arrive au bord de l'inondation, se dire "ah merde, faudrait que je pense à évacuer l'eau"

je suis pas sur que le temps de compiler la regex puis de la vérifier soit plus rapide qu'une exception, mais c'est une idée intéressante.

Brunni (./107) :
Plus sérieusement, on peut coder bien en Java (après tout) mais ce n'est pas ce qu'on enseigne couramment. Tout le monde croit savoir faire du Java, même ceux qui l'ont appris rapidement sur le tas, et aussi ce qu'on trouve sur le net est souvent moche.

Farpaitement d'accord. Faut toujours se demander si ce qu'on vient d'écrire a du sens dans le contexte demandé, c'est un énorme lieu commun mais c'est vrai

Brunni (./107) :
Le problème vient du fait que si on fait un try catch sur toute la validation du formulaire, il n'y a pas moyen d'indiquer spécifiquement ce qui s'est mal passé. C'est pour ça que le modèle est mauvais.

mais non, c'est juste qu'il faut pas faire comme ça. C'est pas parce qu'un langage donne de la liberté qu'il faut la prendre en entier. Tu peux faire de belles saloperies en C, aussi, à ce rythme

Bah c'est pareil dans tous les langages, en même temps... quand on voit ce qui peut être produit en C ou en PHP (l'autre problème étant de se mettre d'accord sur ce qu'est "bien écrire"...)...

squalyl (./108) :
je suis pas sur que le temps de compiler la regex puis de la vérifier soit plus rapide qu'une exception, mais c'est une idée intéressante.

Ben, c'est pareil, la compilation de la regex, on ne la fait qu'une fois (cf ./57 )
Mais effectivement, la vérification doit être lente quand même.

Nil: ça existe pas "bien coder". Y'a juste quelques documents qui décrivent ce qui est acceptable pour certaines catégories de gens, ceux qui ont écrit le doc par exemple

Bof, un minimum de bon sens aide quand même un peu