Est-ce une bonne pratique connue d'utiliser une méthode try-catch par méthode en java? [fermé]

je dirais que si vous vous trouvez à emballer deux blocs de code séparés avec try/catch vous devriez envisager de recadrer ces blocs dans des méthodes séparées. S'il s'agit d'un modèle que vous avez utilisé dans votre entrevue que peut-être vous avez mal compris votre interviewer.

, Il est parfaitement acceptable d'utiliser deux try/catch blocs si l'algorithme exige. J'ai souvent utilisé un nouveau try/catch dans un catch block pour assurer un nettoyage en toute sécurité de sorte qu'une déclaration générale n'est pas possible.

pour répondre à votre question, lorsque nous parlons de JVM modernes qui appliquent en fait beaucoup d'optimisations dans le code, lorsque vous écrivez un code qui est inefficace, alors la JVM introduira automatiquement des optimisations.

s'il vous Plaît se référer à la réponse ( Java: surcharge de l'entrée/à l'aide de "try-catch" blocs? ).

la bonne pratique n'a donc pas beaucoup d'importance.

sur un note personnelle, je crois que l'on ne doit pas encapsuler quoi que ce soit dans un try-catch , static , synchronized etc blocks pas nécessairement.

rendons notre code plus lisible à ceux qui travailleront sur ce sujet. Si une exception est prise, il est préférable de faire explicitement ressortir ce que le morceau de code jette.

pas de devinette pour le lecteur, c'est pourquoi les JVM sont intelligents, écrivez comme vous voulez, faites-le mieux pour les humains et JVM prend soin de l'optimisation de la partie.

EDIT: j'ai lu beaucoup de livres et je n'ai pas trouver la place qui dit qu'un grand try catch est mieux que plusieurs petits.

en outre, beaucoup dans la communauté des développeurs croient le contraire.

j'essaie d'éviter la duplication dans les blocs de capture. Si toutes les exceptions dans une méthode reçoivent le même traitement dans le bloc de capture, alors allez-y et les attraper tous ensemble. Si vous avez besoin de faire des choses différentes avec eux, puis les attraper séparément.

par exemple, ici nous pouvons attraper toutes les exceptions ensemble, parce que toute sorte d'exception signifie l'échec de toute la méthode:

public PasswordAuthentication readAuthenticationDetails(File authenticationFile) {
    try {
        BufferedReader reader = new BufferedReader(new FileReader(authenticationFile));
        String username = reader.readLine();
        String password = reader.readLine();
        return new PasswordAuthentication(username, password.toCharArray());
    } catch (IOException e) {
        return null;
    }
}

alors qu'ici, nous avons un comportement de repli différent pour chaque groupe d'appels, donc nous attrapons séparément:

public Collection<String> readServerHostnames(File mainServerConfigFile, File backupServerConfigFile) {
    String mainServerHostname;
    try {
        BufferedReader reader = new BufferedReader(new FileReader(mainServerConfigFile));
        mainServerHostname = reader.readLine();
    } catch (IOException e) {
        mainServerHostname = "default-server.example.org";
    }

    String backupServerHostname;
    try {
        BufferedReader reader = new BufferedReader(new FileReader(backupServerConfigFile));
        backupServerHostname = reader.readLine();
    } catch (IOException e) {
        backupServerHostname = "default-server.example.ru";
    }

    return Arrays.asList(mainServerHostname, backupServerHostname);
}

(ce code existe uniquement pour illustrer ce point au sujet de la capture d'exceptions; je vous prie de ne pas tenir compte du fait qu'il est tout à fait horrible à d'autres égards)

quant à moi, il est plus clair de n'avoir qu'un seul bloc try-catch enveloppant tout le code "dangereux" dans une méthode. En ce qui concerne qui blâmer quand deux lignes jettent la même exception, vous aurez toujours le stactrace.

en outre, avoir plus d'un try-catch à l'intérieur d'une méthode signifie généralement avoir plus d'une return lignes (qui peuvent également rendre difficile de suivre l'exécution du code à une vue), comme les chances sont que si quelque chose va mal dans le premier try-catch ça n'a pas de sens de continuer à utiliser le reste du code.

vous trouverez ici quelques bonnes pratiques "standard", au cas où vous les trouveriez utiles.-

http://howtodoinjava.com/2013/04/04/java-exception-handling-best-practices /

C'est une autre chose qui commence souvent Java-troll... ;- )

essentiellement, pour les questions de performance seulement jeter des exceptions. Ainsi, l'utilisation de quelques blocs try-catch ne devrait pas affecter une performance du tout. Dans certaines opinions, écrire du code de cette façon obscurcit le code et ne se souvient même pas de "code propre", dans d'autres opinion, il est préférable d'utiliser try seulement pour les lignes qui peuvent réellement jeter n'importe quelle exception.

C'est à vous de décider (ou l'équipe de la convention).

Il est également important de considérer le contexte du code. Si vous écrivez du code avec IO lourd, vous devrez peut-être savoir quelles parties du code échouent. Je n'ai vu nulle part encore un point qui essaie...catch est destiné à vous donner une chance de récupérer d'un problème.

donc si vous obtenez une exception IO dans la lecture d'un fichier, vous pouvez vouloir réessayer la lecture. Même avec l'écriture. Mais si vous aviez un gros essai...attraper vous ne savez pas qui de réessayer.