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

Je dirais que si vous vous retrouvez à envelopper deux blocs de code distincts avec try/catch, vous devriez envisager de refactoriser ces blocs dans des méthodes distinctes. Si c'est un modèle que vous avez utilisé dans votre interview, vous avez peut-être mal compris votre intervieweur.

Il est parfaitement correct d'utiliser deux blocs try/catch si l'algorithme l'exige. J'ai souvent utilisé un nouveau try/catch dans un bloc de capture pour assurer un nettoyage sûr, 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 du code inefficace, la JVM introduira automatiquement des optimisations.

Veuillez vous référer à la réponse dans (Java: surcharge de saisie/utilisation de blocs "try-catch"?).

Donc, la bonne pratique n'a pas beaucoup d'importance.

Sur une note personnelle, je crois qu'il ne faut rien encapsuler dans un try-catch, static, synchronized etc bloque non nécessairement.

Rendons notre code plus lisible pour ceux qui y travailleront. Si une exception est attrapée, il est préférable de la rendre explicitement visible quel morceau de code la lance.

Pas de devinettes pour le lecteur, c'est pourquoi les JVM sont intelligentes, écrivent comme vous voulez , le rendent meilleur pour les humains et la JVM s'occupe de la partie optimisation.

EDIT: J'ai lu beaucoup de livres et je ne l'ai trouvé aucun endroit qui dit cette grosse prise d'essai est meilleure que plusieurs petites.

De plus, 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 d'une méthode reçoivent le même traitement dans le bloc catch, alors allez-y et attrapez-les toutes ensemble. Si vous devez faire différentes choses avec eux, attrapez-les séparément.

Par exemple, ici, nous pouvons attraper toutes les exceptions ensemble, car tout type d'exception signifie que toute la méthode échoue:

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, nous attrapons donc 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 sur la capture des exceptions; je vous prie de ne pas tenir compte du fait que c'est tout à fait horrible d'une autre manière)

Quant à moi, il est plus clair d'avoir un seul bloc try-catch enveloppant tout le code 'dangereux' dans une méthode. En ce qui concerne qui blâmer lorsque deux lignes lancent la même exception, vous aurez toujours la stacktrace.

En outre, avoir plus d'un try-catch dans une méthode signifie généralement avoir plus d'une return lignes (ce qui peut également rendre difficile de suivre l'exécution du code à vue), car il est probable que si quelque chose ne va pas dans le premier try-catch, cela n'aura pas de sens de continuer à exécuter le reste de la code.

Ici vous pouvez trouver quelques bonnes pratiques "standard", juste au cas où vous pourriez les trouver utiles.-

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

C'est une autre chose qui démarre souvent Java-flamewar... ;-)

Fondamentalement, pour la performance ne compte que lancer des exceptions. Donc, l'utilisation de quelques blocs try-catch ne devrait pas affecter une performance du tout. Dans certains avis, écrire du code de cette façon obscurcit le code et ne rappelle même pas le "code propre", dans d'autres avis, il est préférable d'utiliser try uniquement pour les lignes qui peuvent réellement lever une exception.

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

, Il est également important de considérer le contexte du code. Si vous écrivez du code avec des E / S lourdes, vous devrez peut-être savoir quelles parties du code échouent. Je n'ai pas encore vu nulle part 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 d'E / S en lecture à partir d'un fichier, vous pouvez réessayer la lecture. Même chose avec l'écriture. Mais si vous aviez un grand essai...attraper vous ne sauriez pas lequel réessayer.