90

Nil (./86) :
Pen^2 (./65) :
http://en.wikipedia.org/wiki/Category:SQL_keywords
C'est un peu limitant ; par exemple, tu peux faire une requête SQL Oracle sans utiliser un seul des mots clés de la norme SQL cheeky.

Je me doutais que c'était pas une super idée ; de toute façon le principe même de filtrer les mots est dangereux, on peut toujours en oublier.
En JAVA, il faut utiliser les PreparedStatement à priori (les injections sont filtrées directement par le driver JDBC)
Pen^2 (./65) :
Mais je n'ai pas trop l'habitude de protéger du SQL.
Pareil (en fait, en gros, depuis le début du topic, à quelques détails prêt, j'aurais pu écrire "pareil" à tout ce que tu as écrit cheeky. Toi aussi, tu n'es qu'un petit développeur d'informatique de gestion ? tsss

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

91

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 grin





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... cheeky

92

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...
avatar
Highway Runners, mon jeu de racing à la Outrun qu'il est sorti le 14 décembre 2016 ! N'hésitez pas à me soutenir :)

https://itunes.apple.com/us/app/highway-runners/id964932741

93

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.

94

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 grin

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.

95

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

Savoir coder?
#objection#
Il existe une contradiction entre les faits et la déclaration du témoin votre honneur!
Présenter: le titre du topic (.contains("JAVA"))
avatar
Highway Runners, mon jeu de racing à la Outrun qu'il est sorti le 14 décembre 2016 ! N'hésitez pas à me soutenir :)

https://itunes.apple.com/us/app/highway-runners/id964932741

96

Pen^2 (./90) :

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


Ouaaaah, c'est classe !
avatar

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.

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)
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

98

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

Savoir coder? En parlant de Java? Ca mérite une
#objection#
tongue
C'est pas de ma faute si on ne me laisse pas coder en 68k embarrassed

99

Nil (./96) :
Pen^2 (./90) :

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


Ouaaaah, c'est classe !
triclasse, surtout \o/

100

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.

101

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.

102

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 ? cheeky

(et c'est encore plus drôle si tu veux afficher un message du style "le fichier plop.jpg est introuvable" grin)
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

103

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


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

104

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 grin

du coup toutes les exceptions javacard sont statiques tongue

105

-
avatar
Highway Runners, mon jeu de racing à la Outrun qu'il est sorti le 14 décembre 2016 ! N'hésitez pas à me soutenir :)

https://itunes.apple.com/us/app/highway-runners/id964932741

106

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 sick), mais il y a de quoi se taper la tête contre les murs.
avatar
Highway Runners, mon jeu de racing à la Outrun qu'il est sorti le 14 décembre 2016 ! N'hésitez pas à me soutenir :)

https://itunes.apple.com/us/app/highway-runners/id964932741

107

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" cheeky
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

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.
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 grin
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 grin

109

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"...)...
avatar

110

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 tongue)
Mais effectivement, la vérification doit être lente quand même.

111

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 grin

112

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