Discussion :

[blasme]

Salut,

j'aurais voulu un complement d'information concernant le try, catch, finally.
En effet je me pose plusieurs questions

si je fais ceci

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
try{
    methodeXY();
}
catch(Exception ex) {
   throw ex;
}
finally{
 MessageBox.show("blablabla");
}

Est ce que en cas d'exception je verais quand meme ma message box?

Deuxiement chose le meme code mais avec un return ds le catch et meme question.

Merci beaucoup[/code]

[Royd938]

le contenu du bloc finally est toujours exécuter quoiqu'il se passe, exception ou pas exception... maintenant avec un return dans le catch logiquement on sortira de la fonction sans atteindre le bloc finally. Mnt, comme disait mon prof d'algo, un return doit toujours être la dernière instruction d'une fonction au sinon vive le code de merde et vive de GOTO !!!

[blasme]

Ok merci beaucoup pour ta réponse rapide.

Pour le return je ne comptais pas en mettre ds mes catch mais c'etait pour être sur.

Merci


EDIT : et le fait de lancer une exceptions dans le catch, le finally s'exécutera quand meme???

[abelman]

Ton MessageBox sera affiché dans tous les deux cas, exception et return dans le catch.

C'est très simple à tester

[smyley]

en passant avec .NET 1.0 et 1.1 Thread.Abort peut stopper un finally, mais dans le 2.0 je crois que c'est réglé

[abelman]

en passant avec .NET 1.0 et 1.1 Thread.Abort peut stopper un finally, mais dans le 2.0 je crois que c'est réglé

Qu'est que tu entends par stopper un finally ??

[smyley]

Quand un thread appelle Abort sur lui-même, l'effet est similaire à la levée d'une exception ; ThreadAbortException se produit immédiatement et le résultat est prévisible. En revanche, si un thread appelle Abort sur un autre thread, l'abandon interrompt tout code en cours d'exécution. Il est également possible qu'un constructeur statique soit abandonné. Dans de rares cas, cela peut empêcher la création d'instances de cette classe dans ce domaine d'application. Dans les versions 1.0 et 1.1 du .NET Framework, il existe une possibilité que le thread soit abandonné alors qu'un bloc finally est en cours d'exécution, auquel cas le bloc finally est abandonné.

Effrayant

[abelman]

Quand un thread appelle Abort sur lui-même, l'effet est similaire à la levée d'une exception ; ThreadAbortException se produit immédiatement et le résultat est prévisible. En revanche, si un thread appelle Abort sur un autre thread, l'abandon interrompt tout code en cours d'exécution. Il est également possible qu'un constructeur statique soit abandonné. Dans de rares cas, cela peut empêcher la création d'instances de cette classe dans ce domaine d'application. Dans les versions 1.0 et 1.1 du .NET Framework, il existe une possibilité que le thread soit abandonné alors qu'un bloc finally est en cours d'exécution, auquel cas le bloc finally est abandonné.

Effrayant

Effectivement ...
A éviter donc

[Maniak]

Mnt, comme disait mon prof d'algo, un return doit toujours être la dernière instruction d'une fonction au sinon vive le code de merde et vive de GOTO !!!

Avec des méthodes de 200 lignes oui. Mais celles-là doivent être coupées.
Avec des méthodes de 10 lignes on s'en fout. Au contraire même, ça peut faire gagner en lisibilité.

[b_lob]

je deterre ce vieux topic parce que je me demande quelle est l'utilité du bloc finally étant donné que les instruction apres try catch sont forcément executées...


Quel est votre avis sur la question.. ?

[Mose]

Question con, ça sert à quoi un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
catch(Exception exc)
{
    throw(exc);
}

A part à masquer d'où provient effectivement l'erreur dans la trace, je vois pas....

[dim971]

Question con, ça sert à quoi un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
catch(Exception exc)
{
    throw(exc);
}

A part à masquer d'où provient effectivement l'erreur dans la trace, je vois pas....

A faire des remontées d'exception...Par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
private void blabla1 ()
{
	try
	{
	}
	catch(Exception ex1)
	{
		throw(ex1);
	}
}
 
private void blabla ()
{
	try
	{
		blabla1(); // on imagine qu'elle genere l'exception EX
	}
	catch(Exception ex)
	{
		MessageBox.Show(ex.Message); // Ici on aura normalement le message de ex1
	}
}

mais j'ai quand meme un doute....si il y a qqun pour confirmé (infirmé ?)

[Kelpan]

Code c# :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
catch(Exception ex1)
{
throw(ex1);
}

N'a aucune utilité s'il n'y a pas de gestion spécifique de l'erreur.
Même s'il n'y a pas de Catch, l'erreur est remonté jusqu'à la procédure appelante.

D'ailleurs le catch n'est pas obligatoire dans un bloc Try...

Code vb.net :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
Try
  BeginUpdate
 
  '....
 
Finally
  ' Le EndUpdate sera toujours executé même si on rencontre une exception dans le code qui suit BeginUpdate...
  EndUpdate 
End Try