Si existait un concours des fausses idées autour de l’utilisation d’un bloc Try, Catch, Finally en .net, j’en proposerais deux :

1. En cas d’exceptions “très particulières”, On peut sortir d’un Try sans aller dans un Catch générique. Il faut donc coder un Finally et utiliser des variable pour savoir si tout c’est bien passé.

Exemple C# :

// Je déclare des variable
// Je déclare aussi des variable pour savoir si tout c'est bien passé
Boolean toutVaBien = false;
try
{
    // Faire qqchose

    // Fin de qqhcose
    toutVaBien = true;
}
catch(Exception ex)
{
    // Je capture tout
}
finally
{
    // Je corrige mon context car je sais que tout ne s'est pas bien passé
    if (!toutVaBien)
    {

    }
}

Désolé, c’est faux. Si il y a exception, on passera par le catch. Ceci est valable, même si’il y a une exception système (on pourra même savoir ce qu’elle contient). Il n’y a pas d’exception “particulières”, “très particulières”, voir “trop particulières” qui puissent passer à côté du Catch.

Seul cas “possible” : le processus de l’application est coupé. Dans ce cas, le finallly ne sert à rien. Votre application est Off, un point c’est tout ;)

2. Il faut catcher finement ses exceptions pour avoir de meilleures performances et un impacte moindre sur les ressources système.

Exemple C# :

try
{
    // Faire qqchose
}
catch (MyTypedException ex1)
{
    // J'application la corretion générique
    Corriger();
}
catch (Exception ex2)
{
    // J'application la même corretion générique
    Corriger();
}

Désolé, c’est aussi faux. Ce code n’a aucun impact bénéfique. En plus, faire deux fois la même opération dans deux Catch différents. Ce qui induit une redondance inutile ;)

voilà, si vous avez d’autres blagues du genre, il ne faut pas hésitez à les partager.