Publicité

Affichage des résultats du sondage: Êtes-vous pour ou contre cette proposition ?

Votants
385. Vous ne pouvez pas participer à ce sondage.
  • Pour

    334 86,75%
  • Contre

    51 13,25%
+ Répondre à la discussion
Page 8 sur 9 PremièrePremière ... 456789 DernièreDernière
Affichage des résultats 141 à 160 sur 171
  1. #141
    Invité régulier
    Inscrit en
    juillet 2008
    Messages
    8
    Détails du profil
    Informations forums :
    Inscription : juillet 2008
    Messages : 8
    Points : 7
    Points
    7

    Par défaut

    Pourquoi vouloir à tout prix énumérer chaque type d'exception trapée pour au final faire le même traitement ?
    Qu'est-ce qui vous déplait tant dans le fait de ne garder qu'un seul et unique bloc qui trape le type Exception ou éventuellement un type commun plus précis ? Qu'est-ce qui vous manque dans cette solution si simple ?
    Ok, on risque de prendre plus de monde avec une classe mère commune, mais est-ce si grave que cela ?

    Plusieurs d'entre vous l'ont dit : peu importe le type trapé, le traitement au final reste le même et l'exception sera ensuite remontée à l'appelant. Vraiment, je ne vois pas ce que ces syntaxes apportent de vital qui n'existerait pas déja dans le langage, à par une complexité cachée additionnelle et les risques d'incompréhension habituel de ce genre de gadget.

  2. #142
    Membre actif Avatar de austin P.
    Inscrit en
    juin 2004
    Messages
    181
    Détails du profil
    Informations personnelles :
    Âge : 39

    Informations forums :
    Inscription : juin 2004
    Messages : 181
    Points : 183
    Points
    183

    Par défaut

    Citation Envoyé par mavina Voir le message
    Encore une fois je ne comprends pas ou est le probleme : dupliquer le code, c'est pas obligatoire, le code dupliqué pouvait facilement se mettre dans une fonction,
    ce qui vas ajouter une liste sans fin (Déjà qu'on se plain avec les kilomètres de getters/setters....) de méthode private dans ton code source et, que tu le veuille ou non, rendre la lecture plus complexe.
    En plus j'ai du mal à voir comment tu vas les nommer ces méthodes?
    methodeName_exception ? et si tu gère plusieurs fois la même exception dans ta méthode tu fais
    methodeName_exception1
    methodeName_exception2
    methodeName_exception3 ... ?

    pas sur que ce soit très lisible tout ça.
    En essayant continuellement on finit par réussir. Donc : plus ça rate, plus on a de chance que ça marche. (Jacques Rouxel : "Les shadoks")

  3. #143
    Expert Confirmé Sénior
    Avatar de tchize_
    Homme Profil pro
    Responsable de service informatique
    Inscrit en
    avril 2007
    Messages
    20 643
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : Belgique

    Informations professionnelles :
    Activité : Responsable de service informatique
    Secteur : Service public

    Informations forums :
    Inscription : avril 2007
    Messages : 20 643
    Points : 37 969
    Points
    37 969

    Par défaut

    Citation Envoyé par Ithildine Voir le message
    Ok, on risque de prendre plus de monde avec une classe mère commune, mais est-ce si grave que cela ?
    Oui c'est grave, quand ton type commun est "Exception", tu va chopper toutes les runtimeexception qui n'ont probablement rien à voir avec le traitement prévu. Les exceptions imprévues doivent remonter jusqu'à un niveau ou on les gère, pas subir un traitement qui ne leur est pas approprié et disparaitre.
    Tchize (Чиз) faq java, cours java, javadoc. Pensez à et
    Laisse entrer le jour après une nuit sombre. Si tu es toujours là, tu n'es pas faite pour mourir.

  4. #144
    Membre actif Avatar de austin P.
    Inscrit en
    juin 2004
    Messages
    181
    Détails du profil
    Informations personnelles :
    Âge : 39

    Informations forums :
    Inscription : juin 2004
    Messages : 181
    Points : 183
    Points
    183

    Par défaut

    Citation Envoyé par Ithildine Voir le message
    Pourquoi vouloir à tout prix énumérer chaque type d'exception trapée pour au final faire le même traitement ?
    pour ne pas dupliquer ce même traitement

    Citation Envoyé par Ithildine Voir le message
    Qu'est-ce qui vous déplait tant dans le fait de ne garder qu'un seul et unique bloc qui trape le type Exception ou éventuellement un type commun plus précis ?
    hum des outils comme pmd, checkstyle et consort déconseillent tous fortement l'utilisation du catch Exception : je pense qu'il y a une bonne raison à cela.


    Citation Envoyé par Ithildine Voir le message
    Ok, on risque de prendre plus de monde avec une classe mère commune, mais est-ce si grave que cela ?
    oui

    la gestion des exceptions reste une science exacte : peu de place pour de "l'a peu près". Le diagnostic n'en sera que plus simple.

    Citation Envoyé par Ithildine Voir le message
    Plusieurs d'entre vous l'ont dit : peu importe le type trapé, le traitement au final reste le même et l'exception sera ensuite remontée à l'appelant.
    ce n'est pas mon cas
    chaque couche/layer encapsule l'exception et celle ci gagne (en traversant chaque couche) en granularité. Au final ma GUI se fiche pas mal de savoir que la BDD est tombé, ou que le réseau dans la DMZ est indisponible. Elle à juste à savoir que le service est indisponible.

    Citation Envoyé par Ithildine Voir le message
    Vraiment, je ne vois pas ce que ces syntaxes apportent de vital qui n'existerait pas déjà dans le langage, à par une complexité cachée additionnelle et les risques d'incompréhension habituel de ce genre de gadget.
    ce n'est pas vital : c'est juste du confort

    pourquoi avoir un while alors que je peut le simuler avec un for ?
    du confort
    En essayant continuellement on finit par réussir. Donc : plus ça rate, plus on a de chance que ça marche. (Jacques Rouxel : "Les shadoks")

  5. #145
    Membre confirmé
    Inscrit en
    mai 2007
    Messages
    241
    Détails du profil
    Informations forums :
    Inscription : mai 2007
    Messages : 241
    Points : 270
    Points
    270

    Par défaut Enfin décidé: a voté oui

    J'avais déjà exprimé mes réticences, mais ça peut être un plus pour la lisibilité, donc vous m'avez convaincu.
    Mais il reste le problème du type catché, pour moi soit on indique le type parent à utiliser, soit c'est "Throwable" tout le temps, qui est suffisant dans la plupart des cas.
    Ce qui dans ce cas donne quelque chose comme:

    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
     
    	try {
    		Object test = Class.forName("aaa").newInstance();
    	} catch (InstantiationException, IllegalAccessException,ClassNotFoundException  e) {
    		e.printStackTrace();
    		//si vraiment on veut typer
    		doSomething((Exception) e);
    	}
     
    }
    il faut vraiment éviter un typage automatique de "e" en "Exception" (la superclasse commune dans mon exemple).

  6. #146
    Expert Confirmé
    Avatar de mavina
    Homme Profil pro Frédéric Mora
    Développeur Java
    Inscrit en
    octobre 2004
    Messages
    1 812
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric Mora
    Âge : 28
    Localisation : Chine

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : Conseil

    Informations forums :
    Inscription : octobre 2004
    Messages : 1 812
    Points : 2 649
    Points
    2 649

    Par défaut

    Citation Envoyé par austin P. Voir le message
    ce qui vas ajouter une liste sans fin (Déjà qu'on se plain avec les kilomètres de getters/setters....) de méthode private dans ton code source et, que tu le veuille ou non, rendre la lecture plus complexe.
    En plus j'ai du mal à voir comment tu vas les nommer ces méthodes?
    methodeName_exception ? et si tu gère plusieurs fois la même exception dans ta méthode tu fais
    methodeName_exception1
    methodeName_exception2
    methodeName_exception3 ... ?

    pas sur que ce soit très lisible tout ça.
    Euh, si toutes tes exceptions sont catchées en même temps, tu n'as qu'une fonction à faire, que tu places dans chaque catch...
    Une fonction private donc, ce n'est pas la mort à trouver un nom pour une fonction qui traite un cas d'exceptions commun...

    F.
    Développeur Java / Flex à Shanghai, Chine
    mes publications
    Mon dernier tutoriel : Messages Quit IRC : explications

    La rubrique IRC recrute des redacteurs : contactez moi

    Ce flim n'est pas un flim sur le cyclimse. Merci de votre compréhension.[/SIZE]

  7. #147
    Membre actif Avatar de austin P.
    Inscrit en
    juin 2004
    Messages
    181
    Détails du profil
    Informations personnelles :
    Âge : 39

    Informations forums :
    Inscription : juin 2004
    Messages : 181
    Points : 183
    Points
    183

    Par défaut

    Citation Envoyé par mavina Voir le message
    Euh, si toutes tes exceptions sont catchées en même temps, tu n'as qu'une fonction à faire, que tu places dans chaque catch...
    Une fonction private donc, ce n'est pas la mort à trouver un nom pour une fonction qui traite un cas d'exceptions commun...
    F.
    cela ne vaut que si et seulement si tu n'a qu'un cas de gestion d'exception dans une classe et c'est un cas peu probable voir improbable. Prenons une classe contenant 30 methodes, j'ai peine à croire qu'une seule gestion d'exception suffise même si cette classe est fortement cohésive.

    Ici on ne cherche pas à regrouper tous les cas d'exception d'une classe vers une seule méthode mais bien de pouvoir faire un regroupement de gestion d'exception suivant leur affinité fonctionnelle/technique.

    tu te retrouvera donc bien avec un ensemble de méthodes private pour la gestion des exception.


    Pour ajouter à mon propos, je pense aussi que d'utiliser des méthodes private pose aussi un problème de porté. En effet si je modifie une de ces méthodes private, je peux difficilement dire (et vérifier) si cette modification est bonne pour tous les bloc catch de ma classe qui la pointe.

    Ici on recherche moins à éviter le copier-coller dans toute une classe que de simplifier et de rendre plus lisible/moins envahissante la gestion des exceptions.
    En essayant continuellement on finit par réussir. Donc : plus ça rate, plus on a de chance que ça marche. (Jacques Rouxel : "Les shadoks")

  8. #148
    Expert Confirmé Sénior
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 680
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 680
    Points : 6 961
    Points
    6 961

    Par défaut

    Et encore, ça suppose que la méthode de gestion d'exception n'ait pas besoin de variables ou de références appartenant au contexte de la méthode dans laquelle se trouve le code qui a déclenché l'erreur.

    C'est un excellent progrès à mon sens car je trouve que c'est justement sur ce genre de chose que java a du retard par rapport à son concurrent c#.

  9. #149
    Expert Confirmé Sénior


    Inscrit en
    octobre 2003
    Messages
    7 895
    Détails du profil
    Informations forums :
    Inscription : octobre 2003
    Messages : 7 895
    Points : 30 544
    Points
    30 544

    Par défaut

    Citation Envoyé par _skip Voir le message
    C'est un excellent progrès à mon sens car je trouve que c'est justement sur ce genre de chose que java a du retard par rapport à son concurrent c#.
    Bonjour,

    Je suis assez surpris par ta remarque (mais je ne connais pas suffisamment C#). Pourrais tu illustrer ton propos ?

  10. #150
    Expert Confirmé Sénior
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 680
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 680
    Points : 6 961
    Points
    6 961

    Par défaut

    Bonjour,
    Je suis assez surpris par ta remarque (mais je ne connais pas suffisamment C#). Pourrais tu illustrer ton propos ?
    Le sujet a été débattu sur le forum best of des débats. Le C# offre la syntaxe "throw;" qui permet de propager une exception depuis un bloc catch sans perte de la stacktrace originale, et donc sans le besoin d'encapsulation.
    Pour les cas ou je me fiche de savoir quel est le type de l'exception déclenché mais que je veux juste pouvoir déclencher un rollback ou effectuer un nettoyage (et c'est le cas 9 fois sur 10 dans ma BLL), c'est un gain en code et en lisibilité considérable.

    En gros on peut faire un code du style :

    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    try
    {
         //code déclenchant une exception
    }
    catch(Exception ex)
    {
          if( !(ex is MonException1 || ex is MonException2 || ex is MonException3 )  )
                 throw;
     
          //gérer un cas général d'exception ici, afficher un message etc...
    }
    Ou encore de ce genre :

    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    try
    {
         //code déclenchant une exception
    }
    catch(Exception ex)
    {
          if(connection.IsOpen() )
          {
                  Transaction.Rollback();
                  connection.close();
          }
     
          throw; //propager
    }

    Cette nouvelle syntaxe en java permet justement de répondre à tous ces cas ou on se fiche du type exact de l'exception, mais qu'on veut simplement être en mesure de réagir à une erreur avant de propager l'exception plus haut.
    On fait cela très souvent dans les applications n-tiers, on veut que la couche profonde signale que quelque chose de mauvais est arrivé mais la décision d'arrêter l'application ou de continuer l'exécution après un gentil message d'erreur est prise par la couche de surface.

  11. #151
    Membre éprouvé Avatar de djsnipe
    Inscrit en
    mai 2008
    Messages
    440
    Détails du profil
    Informations forums :
    Inscription : mai 2008
    Messages : 440
    Points : 440
    Points
    440

    Par défaut

    Je ne vois pas dans ce code quelque chose de plus qu'en Java aujourd'hui :
    - On catch une Exception de haut niveau et après on teste le type réel. En Java, pareil catch(Exception e) puis des instanceof
    - Propagation d'exception, sans rien perdre non plus, mais ok en java il faut rajouter le nom de la variable contenant l'exception, donc "throw ex" dans ton exemple au lieu de "throw".

    Où est l'avantage du C# ?

  12. #152
    Expert Confirmé Sénior
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 680
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 680
    Points : 6 961
    Points
    6 961

    Par défaut

    Je ne vois pas dans ce code quelque chose de plus qu'en Java aujourd'hui :
    - On catch une Exception de haut niveau et après on teste le type réel. En Java, pareil catch(Exception e) puis des instanceof
    Tu peux pas faire ce genre de chose, si tu essaies de relancer Exception, tu vas être obligé de mettre des catch( Exception ) partout sur toute les méthodes appelantes car Exception est une checked exception.

    - Propagation d'exception, sans rien perdre non plus, mais ok en java il faut rajouter le nom de la variable contenant l'exception, donc "throw ex" dans ton exemple au lieu de "throw".
    Si tu fais throw ex, que ce soit en java ou en C#, tu perds une partie précieuse des informations de la pile, en fait ça donnera l'impression que c'est ton code de gestion d'erreur qui a déclenché l'exception, alors qu'en vérité c'est quelque chose dans le code du bloc try plus haut.

  13. #153
    Membre éprouvé Avatar de djsnipe
    Inscrit en
    mai 2008
    Messages
    440
    Détails du profil
    Informations forums :
    Inscription : mai 2008
    Messages : 440
    Points : 440
    Points
    440

    Par défaut

    Tes 2 explications sont sur le fait de relancer l'exception.
    Le gros catch en C# que tu décrit reste pour moi identique en Java.
    Maintenant, les "précieuses informations de la pile", et le simple "throw" du C#, je ne vois toujours pas. Si dans ton exemple, le throw propage l'exception, pourquoi ne faudrait-il pas la catcher au niveau supérieur ? Pour la pile, si je choisi de faire un catch, c'est bien justement que je souhaite traiter l'erreur à mon niveau. Pour faire remonter des erreurs de couche en couche, je ne propage jamais l'exception initiale, ca ajoute du couplage inutile entre une couche de présentation et de persistance. Donc systématiquement, j'encapsule et je ne perd pas d'info. Et quand je ne peux pas traiter une exception qui par nature serait irrécupérable, je la propage justement en Runtime.

    Au final, d'après tes explications, C# et Java sont sensables, ils permettent de faire la même chose, à qq pouillièmes de syntaxe.

    [Edit] Je ne relancerai pas le topic sur cette apartée, trop éloignée du sujet initial.

  14. #154
    Expert Confirmé Sénior
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 680
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 680
    Points : 6 961
    Points
    6 961

    Par défaut

    Si dans ton exemple, le throw propage l'exception, pourquoi ne faudrait-il pas la catcher au niveau supérieur ?
    Le but d'une exception c'est pas forcément qu'on la catche, seul 1/5 à peine de mes blocs try ont une clause catch(), par contre beaucoup de finally. Les seuls moments ou une clause catch m'intéresse ne sont pratiquement que ceux pour lesquelles j'ai un rollback à effectuer. Je ne vais pas m'amuser à catcher des exceptions partout si c'est pour ne rien faire de plus qu'un handler global.

    Pour faire remonter des erreurs de couche en couche, je ne propage jamais l'exception initiale, ca ajoute du couplage inutile entre une couche de présentation et de persistance. Donc systématiquement, j'encapsule et je ne perd pas d'info.
    Je suis un peu différent, je déteste l'idée de décorer des exceptions juste pour avoir de l'abstraction sur les couches inférieures sans ajouter aucune information ou aucune fonctionnalité. Je le fais seulement si les exceptions remontées n'ont pas de sens ou sont imprécises aux yeux de la couche appelante.

    Et quand je ne peux pas traiter une exception qui par nature serait irrécupérable, je la propage justement en Runtime.
    Donc ça veut dire que c'est ta couche inférieure et non celle de surface qui décide de la réaction de l'application à une situation d'erreur, j'ai une philosophie différente. Si une exception est levée parce qu'une connexion à un service échoue, dans mes programmes c'est la couche UI qui décide si elle veut terminer l'appli, ou proposer de réessayer, dans tous les cas ce qui m'împorte c'est d'avoir bien nettoyer derrière moi, fermer les connexions et annuler les transactions.

    Ca ferait un excellent débat ça.

  15. #155
    Membre Expert
    Avatar de xavlours
    Inscrit en
    février 2004
    Messages
    1 833
    Détails du profil
    Informations forums :
    Inscription : février 2004
    Messages : 1 833
    Points : 2 176
    Points
    2 176

    Par défaut

    Citation Envoyé par _skip Voir le message
    Le sujet a été débattu sur le forum best of des débats. Le C# offre la syntaxe "throw;" qui permet de propager une exception depuis un bloc catch sans perte de la stacktrace originale, et donc sans le besoin d'encapsulation.
    C'est vrai que c'est actuellement impossible en java, et l'exemple de code est pertinent : en java la syntaxe ne permet pas de catcher "tout sauf les Exception de type Exception1, Exception2, etc". On est obligés de passer par l'encapsulation de l'exception "cause" dans une nouvelle exception "effet":
    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    try {
     
    } catch(Exception cause) {
      if(cause instanceof Exception1 || cause instanceof Exception2 || ...) {
        Exception effet = new TrucException(cause);
        throw effet;
        // la stack trace de 'effet' est suivie de la mention "caused by"
        // puis de la stack trace de 'cause'
      }
     
      // on gère les autres types d'exceptions
    }
    Par contre, la fonctionnalité sur laquelle tu t'appuies pour éviter l'encapsulation est le rethrow d'exceptions, en débat dans cette discussion plutôt que le catch multiple, non ?
    "Le bon ni le mauvais ne me feraient de peine si si si je savais que j'en aurais l'étrenne." B.V.
    Non au langage SMS ! Je ne répondrai pas aux questions techniques par MP.
    Eclipse : News, FAQ, Cours, Livres, Blogs.Et moi.

  16. #156
    Expert Confirmé Sénior
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 680
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 680
    Points : 6 961
    Points
    6 961

    Par défaut

    Il me semble que c'est bien le rethrow qui fait l'objet de l'autre proposition. Pas encore regardé d'assez près pour être sûr. Mais vraiment ça y ressemble.

    Cette proposition et celle que tu as pointé sont deux solutions acceptables je trouve. Le problème de fond est toujours un peu le même, il y a aucune syntaxe qui permet de laisser l'exception telle quelle tout en ayant la possibilité de réagir à l'erreur ou tout au moins d'éviter la duplication du code de gestion.
    C'est utile pour tout ce qui ne peut pas se faire avec une clause finally (un rollback dans le cas d'une BDD par ex.).

    Je trouve que ces nouveautés iraient dans le bon sens, de toutes façons il y a forcément des cas dans lesquels ces choses sont pertinentes et d'autres ou elles ne le sont pas vraiment.

  17. #157
    Membre confirmé
    Inscrit en
    mai 2007
    Messages
    241
    Détails du profil
    Informations forums :
    Inscription : mai 2007
    Messages : 241
    Points : 270
    Points
    270

    Par défaut La bonne utilisation du try catch finally

    Que ce soit dans l'ancienne ou dans la nouvelle syntaxe il ne FAUT PAS catcher directement Exception ou pire: Throwable, mais directement les types que l'on doit traiter.
    1. utiliser finally quand on doit faire un traitement avant une sortie d'exception (le rollback le plus souvent) (edit: oops pas le rollback mais la fermeture de connection)

    2. faire un catch pour faire ensuite un rethrow sans encapsulation ça n'est pas efficace et inutile: autant faire simple (lancer et catcher une exception est couteux, le instanceOf est également couteux)

    3. même si le risque est faible, il y a toujours un risque qu'un traitement d'exception plante et on perd alors l'exception originelle: le traitement est faux.

    Finalement, le seul cas ou il faut catcher toutes les exception est le plus haut niveau d'un serveur d'application, d'un service, bref quand on traite réellement les exceptions sans les relancer.

    Il doit y avoir de bien meilleure sources que moi sur le bon usage de l'exception, mais à ma connaissance aucune ne conseille de catcher l'exception. Il faut rappeler ce qui nous semble les "règles de l'art", plutôt que proposer des contournements.

    en conclusion, cette nouvelle syntaxe nous inciterait à utiliser correctement les exceptions en simplifiant la syntaxe du catch.

  18. #158
    Expert Confirmé Sénior
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 680
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 680
    Points : 6 961
    Points
    6 961

    Par défaut

    -Tu peux tout à fait catcher exception du moment que tu fais une propagation en bonne et due forme et sans perte de l'information, java impose d'éviter ce genre de chose à cause des checked exceptions, mais dans d'autres langages c'est possible et tout à fait propre et sérieux.

    -finally ça se déclenche aussi si tout s'est bien passé, c'est l'endroit idéal pour libérer des ressources mais pas pour effectuer un rollback.

    -Si l'exception est exceptionnelle on s'en fout de perdre même 100ms en rethrow. Typiquement un cas ou on doit faire un rollback ça devrait pas être tous les 2 appels.

  19. #159
    Expert Confirmé
    Avatar de ®om
    Inscrit en
    janvier 2005
    Messages
    2 813
    Détails du profil
    Informations forums :
    Inscription : janvier 2005
    Messages : 2 813
    Points : 2 828
    Points
    2 828

    Par défaut

    Citation Envoyé par _skip Voir le message
    Si l'exception est exceptionnelle
    Dans ce cas, sa gravité est gravitationnelle.


  20. #160
    Expert Confirmé Sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 026
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : avril 2002
    Messages : 13 026
    Points : 20 808
    Points
    20 808

    Par défaut

    Citation Envoyé par _skip Voir le message
    Le sujet a été débattu sur le forum best of des débats. Le C# offre la syntaxe "throw;" qui permet de propager une exception depuis un bloc catch sans perte de la stacktrace originale, et donc sans le besoin d'encapsulation.
    Pour les cas ou je me fiche de savoir quel est le type de l'exception déclenché mais que je veux juste pouvoir déclencher un rollback ou effectuer un nettoyage (et c'est le cas 9 fois sur 10 dans ma BLL), c'est un gain en code et en lisibilité considérable.

    En gros on peut faire un code du style :

    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    try
    {
         //code déclenchant une exception
    }
    catch(Exception ex)
    {
          if( !(ex is MonException1 || ex is MonException2 || ex is MonException3 )  )
                 throw;
     
          //gérer un cas général d'exception ici, afficher un message etc...
    }
    [/quote]
    Désolé mais ceci est tout à fait possible en Java également, à une nuance syntaxique près puisqu'il faut faire suivre le throw par la référence de l'exception :
    Citation Envoyé par _skip Voir le message
    Tu peux pas faire ce genre de chose, si tu essaies de relancer Exception, tu vas être obligé de mettre des catch( Exception ) partout sur toute les méthodes appelantes car Exception est une checked exception.
    La différence est bien là ! En C# il n'y a pas de checked exception, contrairement à Java...

    C'est un choix philosophique de ces deux langages, et chacun ayant ses avantages et ses défauts. Java force les développeurs à gérer les checked-exceptions, tandis qu'en C# on peut ignorer toutes les exception.

    Mais perso cela importe peu car la qualité de la gestion des exception dépend du développeur et non pas du langage...

    Citation Envoyé par _skip Voir le message
    Si tu fais throw ex, que ce soit en java ou en C#, tu perds une partie précieuse des informations de la pile, en fait ça donnera l'impression que c'est ton code de gestion d'erreur qui a déclenché l'exception, alors qu'en vérité c'est quelque chose dans le code du bloc try plus haut.
    Faux, lorsque tu fais un throw l'exception est remonté tel quel et son stacktrace n'est pas modifié. Le stacktrace d'une exception est déterminé lors de sa création...

    Ce n'est que lorsqu'on crée une nouvelle exception que l'on perd le stacktrace initiale, mais on utilise alors la forme suivante qui permet de passer l'exception cause :
    Code :
    throw new MonException("message", ex);

    Citation Envoyé par _skip Voir le message
    -Tu peux tout à fait catcher exception du moment que tu fais une propagation en bonne et due forme et sans perte de l'information, java impose d'éviter ce genre de chose à cause des checked exceptions, mais dans d'autres langages c'est possible et tout à fait propre et sérieux.
    La seule chose que Java impose, c'est de déclarer les checked-exception que l'on remonte...


    a++

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •