Nous avons vu de nombreuses questions sur quand et pourquoi utiliser try
/ catch
et try
/ catch
/ finally
. Et je sais qu'il y a définitivement un cas d'utilisation pour try
/ finally
(d'autant plus que c'est la façon dont le using
est mise en œuvre).
Nous avons également vu des questions sur la surcharge de try/catch et des exceptions .
La question à laquelle j'ai fait référence ne parle cependant pas des frais généraux liés à la présence de JUST try-finally.
En supposant qu'il n'y a pas d'exception à tout ce qui se passe dans le cadre de la try
quel est l'intérêt de s'assurer que les finally
sont exécutées lorsque l'on quitte le try
(parfois en revenant de la fonction) ?
Encore une fois, je demande UNIQUEMENT try
/ finally
non catch
pas de levée d'exceptions.
Merci !
EDIT : Ok, je vais essayer de montrer un peu mieux mon cas d'utilisation.
Lequel dois-je utiliser ? DoWithTryFinally
ou DoWithoutTryFinally
?
public bool DoWithTryFinally()
{
this.IsBusy = true;
try
{
if (DoLongCheckThatWillNotThrowException())
{
this.DebugLogSuccess();
return true;
}
else
{
this.ErrorLogFailure();
return false;
}
}
finally
{
this.IsBusy = false;
}
}
public bool DoWithoutTryFinally()
{
this.IsBusy = true;
if (DoLongCheckThatWillNotThrowException())
{
this.DebugLogSuccess();
this.IsBusy = false;
return true;
}
else
{
this.ErrorLogFailure();
this.IsBusy = false;
return false;
}
}
Ce cas est excessivement simpliste car il n'y a que deux points de retour, mais imaginez s'il y en avait quatre... ou dix... ou cent.
A un moment donné, je voudrais utiliser try
/ finally
pour les raisons suivantes :
- Respecter les principes du DRY (surtout lorsque le nombre de points de sortie augmente).
- S'il s'avère que je me trompe en disant que ma fonction interne ne lève pas d'exception, alors je veux m'assurer que
this.Working
est réglé surfalse
.
Donc hypothétiquement, étant donné les problèmes de performance, la maintenabilité et les principes DRY, pour quel nombre de points de sortie (surtout si je peut en supposant que toutes les exceptions internes sont rattrapées), est-ce que je veux subir une quelconque pénalité de performance associée à try
/ finally
?
EDIT #2 : J'ai changé le nom de this.Working
à this.IsBusy
. Désolé, j'ai oublié de préciser qu'il s'agit d'une méthode multithread (bien qu'un seul thread n'appelle jamais la méthode) ; les autres threads s'interrogent pour savoir si l'objet effectue son travail. La valeur de retour est simplement un succès ou un échec pour savoir si le travail s'est déroulé comme prévu.