Question de gestion des exceptions

Question

J'ai une question concernant la gestion des exceptions. Pensez à suivre l'extrait de code Java.

         try{
            //code
        }catch(SubSubException subsubex){
            //code
        }catch(SubException subex){
            //code
        }catch(Exception ex){
            //code
        }
 

Je sais que c'est la façon recommandée de gérer les exceptions. Mais je peux réaliser la même chose en utilisant l'extrait de code suivant.

         try{
            //code
        }catch ( Exception ex){
            if( ex instanceof SubException){              
                //code
            }else if(ex instanceof SubSubException){
                //code
            }else{
                //code
            }
        }
 

Quelqu'un peut-il me dire les inconvénients de la deuxième approche?

Answer 1

La deuxième approche est moins lisible. De plus, la gestion des exceptions Pokemon n'est jamais la voie à suivre même si votre astuce "intelligente" consiste à utiliser le mot-clé instanceof. Je ne me moque pas de vous ou ne vous moquez pas de toute façon, mais il est préférable d'écrire du code pour que les humains le lisent et le maintiennent, pas pour l'ordinateur.

Answer 2

Oui, MadMurf souligne la différence la plus importante: l'accessibilité à vérifier au moment de la compilation. La norme de l'idiome serait attraper quelque chose comme cela, et avec raison, de l'empêcher de la compilation:

    try {
    } catch (IndexOutOfBoundsException iooe) {
    } catch (ArrayIndexOutOfBoundsException aiooe) {
    }

Le si/instanceof analogique proposé dans la question d'origine serait la compilation (ce qui n'est PAS ce que vous voulez parce que c'est erroné).

La raison pour laquelle la norme de l'idiome des captures de l'erreur au moment de la compilation est donné dans JLS 14.21 Inaccessible États.

• Un bloc catch C est accessible ssi les deux conditions suivantes sont remplies:
  • [...]
  • Il n'y a pas plus tôt bloc catch Un dans l'instruction try telles que le type de C paramètre est le même que ou une sous-classe du type d'Un paramètre.

Pour illustrer ce point, le suivant compile:

    try {
    } catch (Exception e) {
        if (e instanceof Exception) {
        } else if (e instanceof Exception) {
        }
    }

Comme vous pouvez le voir, cette "pokemon attraper" l'idiome est beaucoup plus difficile à maintenir, car il contourne certains moment de la compilation d'accessibilité vérifier appliquées dans la norme de l'idiome.

Pour faire le point encore plus clair, si vous l'avez fait exprès ou pas, vous avez réellement réorganisé l'ordre dans lequel vous avez coché les exceptions dans votre question initiale, un fait qui aurait facilement pu être oubliée par les autres. Si SubSubException est une sous-classe de SubException, la deuxième si la condition ne sera JAMAIS évalué, et que son corps est effectivement inaccessible code.

Le si/instanceof approche est TRÈS sujettes à des erreurs.

Answer 3

hmm, pourquoi devez-vous même faire la deuxième approche? rappelez-vous ceci, à moins que d'autres options ne soient meilleures en termes de performances, de lisibilité, etc., vous devriez vous en tenir aux conventions. La déclaration catch a été conçue à l'origine pour gérer la classification des types d'exceptions qui lui sont propres, alors utilisez-les tels quels ... juste une idée! ...

Answer 4

Le deuxième cas est un code java parfaitement valide, mais il a une plus grande complexité cyclomatique sans ajouter de valeur supplémentaire.

Answer 5

La deuxième approche est nettement moins lisible car:

• il faut plus de symboles,

• il nécessite une indentation plus profonde,

• ce n'est pas idiomatique.

Et l'OMI, le dernier est le plus important. Vous devez écrire votre code d'une manière que les autres programmeurs Java s'attendent à ce qu'il soit écrit.