J'ai dit qu'il y a une surcharge en utilisant le Java try-catch mécanisme. Ainsi, s'il est nécessaire de placer des méthodes qui jettent vérifié exception à l'intérieur d'un bloc try pour gérer l'exception possible, il est de bonne pratique au niveau des performances de limiter la taille du bloc try ne contiennent que celles de ces opérations qui pourraient lancer des exceptions.
Je ne suis pas si sûr que ce est une conclusion logique.
Considérons les deux implémentations ci-dessous d'une fonction qui traite un fichier texte spécifié.
Même si il est vrai que la première entraîne certains surcharge inutile, je trouve ça beaucoup plus facile à suivre. Il est difficile de savoir exactement où les exceptions viennent seulement de regarder des états, mais les observations montrent clairement quels états sont responsables.
Le second est beaucoup plus long et compliqué que le premier. En particulier, la belle ligne de lecture de l'idiome de la première a être déformés pour s'adapter à l' readLine appel dans un bloc try.
Quelle est la meilleure pratique pour la gestion des exceptions dans une fonction où de multiples exceptions pourraient être jeté dans sa définition?
Celui-ci contient tout le code de traitement dans le bloc try:
void processFile(File f)
{
try
{
// construction of FileReader can throw FileNotFoundException
BufferedReader in = new BufferedReader(new FileReader(f));
// call of readLine can throw IOException
String line;
while ((line = in.readLine()) != null)
{
process(line);
}
}
catch (FileNotFoundException ex)
{
handle(ex);
}
catch (IOException ex)
{
handle(ex);
}
}
Celui-ci contient uniquement les méthodes qui renvoient des exceptions dans les blocs try:
void processFile(File f)
{
FileReader reader;
try
{
reader = new FileReader(f);
}
catch (FileNotFoundException ex)
{
handle(ex);
return;
}
BufferedReader in = new BufferedReader(reader);
String line;
while (true)
{
try
{
line = in.readLine();
}
catch (IOException ex)
{
handle(ex);
break;
}
if (line == null)
{
break;
}
process(line);
}
}
