Discussion :

[tarikbenmerar]

PHP intègre désormais un bloc "Finally"
Pour une gestion plus propre des sorties d'exceptions


Xinchen Hui, développeur du projet PHP, a commité hier l'introduction du mot clé "finally" dans le corps du langage.

Cette fonctionnalité, à mainte reprise sollicitée par la communauté, vient d'être officiellement intégrée au langage après un vote favorable ce lundi. Sa RFC (demande de commentaires) a reçu 25 oui (dont celui de Rasmus Lerdorf) contre 5 refus.



finally permet d'éviter au développeur d'écrire un code de nettoyage lorsqu'une exception non manipulable se produit, comme illustré dans le code suivant :

Code :

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

1
2
3
4
5
6
7
8
9
$db = mysqli_connect(); 
try {
   call_some_function($db);
} catch (Exception $e) {
   mysqli_close($db); 
   throw $e;
}
mysqli_close($db);

L'introduction de finally fournit au développeur une manière plus propre de gérer ce genre de problématiques. Le bloc finally s'exécute toujours lorsqu'on quitte le bloc try. Cela permet d'exécuter le bloc finally même si une exception inattendue se produit :

Code :

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

1
2
3
4
5
6
7
$db = mysqli_connect(); 
try {
   call_some_function($db); //La fonction peut produire des exceptions sur lequelles on ne peut intervenir anticiper
} finally {
   mysqli_close($db); 
}

Mais c'est aussi utile lorsque le code de nettoyage est contourné de façon accidentelle par un return, un continue ou un break, comme illustré ci-dessous :

Code :

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

1
2
3
4
5
6
7
8
try {
    return 2;
} finally {
    echo "this will be called\n";
}
//this will never be called
echo "you can not see me";

Ce code affichera « this will be called ». Le texte après le bloc try/finally ne sera pas affiché.

On peut envisager des scénarios plus sophistiqués, avec un cas imbriqué :

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
function foo ($a) {
   try {
      echo "1";
      try {
        echo "2";
        throw new Exception("ex");
      } catch (Exception $e) {
        echo "3";
      } finally {
        echo "4";
        throw new Exception("ex");
      }
   } catch (Exception $e) {
      echo "3";
   } finally {
      echo "2";
   }
   return 1;
}
var_dump(foo("para"));

Ce commit n'a pas engendré l'annonce (ou le lancement) d'une nouvelle version du langage. Les plus téméraires peuvent compiler la dernière branche du langage à partir de son code source.


Source : finally sur le wiki de PHP

Et vous ?

Que pensez-vous de l'intégration de ce mot clé en PHP ?
Comment faisiez-vous sans sa présence ?

[Gugelhupf]

Que pensez-vous de l'intégration de ce mot clé en PHP ?
Je pense que c'est une bonne nouvelle, les développeurs PHP (ou autres ) reprochaient souvent le manque du mot-clé finally.

Comment faisiez-vous sans sa présence ?
"Comme tout le monde ?" J'ai envie de dire... en se débrouillant.
Pour ma part je n'ai pas eu beaucoup l'occasion de rencontrer les problèmes cités en PHP.
En même temps, comment font ceux qui font du C++ et qui n'ont toujours pas le bloc finally ?

[ProgrammeurDotNet]

Quand il n'y a pas de finally, ben une simple condition.
Mais bon, en ce qui me concerne je l'ai en C#. Mais c'est une bonne nouvelle de l'avoir en php.

[ternel]

En C++ on fait du RIIA, c'est à dire une classe encapsulant la ressource.

Le finally est implicite: destruction de toute les variables locales.

L'équivalent c++ de :

Code :

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

1
2
3
4
5
6
cx = createConnection(...)
try{
    useConnection();
} finally {
    killConnection()
}

est:

Code :

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

1
2
3
4
{
Connection cx(...);
cx.use();
}

Parce que le destructeur de cx sera appelé à la sortie du bloc d'accolade.

[Paul TOTH]

c'est pas mal...mais c'est pas prêt d'arriver sur l'ensemble des hébergeurs et clients

[arkadih]

je trouve aussi que c'est une bonne chose, que les développeurs de différents langages retrouvent leurs habitudes, le souci restant que les fonctions natives de php ne jettent pas nécessairement d'exception lors de problèmes rencontrés (certaines jouent sur la valeur de retour, certaines jettent l'exception).
tant que ce souci ne sera pas résolu, php sera toujours en retard au niveau des exceptions de mon point de vue.

[Guilp]

finally...

(désolé. pas pu m'en empêcher )

[iubito]

C'est une belle avancée, mais bien d'accord avec arkadih

J'ai pas souvenir d'avoir utilisé des exceptions en PHP, faut dire que ça fait un bail que je n'en ai pas fait à un gros niveau.

En java je ne peux me passer du finally, mais toutes les fonctions jettent des exceptions (erreur de syntaxe sql, erreur de connexion à la BDD...), en PHP il faudra tester les valeurs de retour et déclencher soi-même l'exception.

[moriarti13]

Pas sur de la pertinence de la chose en PHP.

y'a une bonne partie des dev' PHP qui ne savent même pas ce qu'est un try..catch...

[dourouc05]

y'a une bonne partie des dev' PHP qui ne savent même pas ce qu'est un try..catch...

À commencer par le wiki PHP : dans la coloration syntaxique, try et catch ne sont pas reconnus... Pourtant, ce n'est pas si compliqué de mettre à jour une syntaxe pour GeSHi (utilisé par leur DokuWiki) ...

D'ailleurs, un finally n'est pas toujours la meilleure chose au monde : si on met un return dans les blocs try ou catch, le contenu du finally sera exécuté avant le retour de fonction, c'est-à-dire qu'on ne peut plus suivre simplement le fil d'exécution du code (ça vous rappelle GOTO ?).

[Xinu2010]

D'ailleurs, un finally n'est pas toujours la meilleure chose au monde : si on met un return dans les blocs try ou catch, le contenu du finally sera exécuté avant le retour de fonction, c'est-à-dire qu'on ne peut plus suivre simplement le fil d'exécution du code (ça vous rappelle GOTO ?).

Ouais enfin c'est mettre un return dans un catch qui est sale, pas le finally lui même

[Xinu2010]

En java je ne peux me passer du finally, mais toutes les fonctions jettent des exceptions (erreur de syntaxe sql, erreur de connexion à la BDD...), en PHP il faudra tester les valeurs de retour et déclencher soi-même l'exception.

Il y a des exceptions généré directement par les méthodes de l'API, comme PDOException pour les erreur sql, mais ouais c'est un peu brouillon et pas forcément uniforme.

[Lupus Michaelis]

Je n'ai jamais compris l'intérêt de finally. Comme en a parlé leternel, le RIIA est fait pour ça. Utiliser les exception sans RIIA, c'est un peu un non-sens.

Ceci dit, PHP est un langage sale, à rustine. Et plutôt que d'avoir une gestion du scope de variables cohérent, un emplâtre finally est rajouté...

[transgohan]

Ouais enfin c'est mettre un return dans un catch qui est sale, pas le finally lui même

Quand tu traites plusieurs exceptions au sein d'une fonction tu peux avoir deux comportements en cas d'erreur :

• L'erreur n'est pas bloquante ou peut être corrigée => la fonction se poursuie
• L'erreur est innacceptable => return avec un code d'erreur

Je ne vois absolument pas en quoi c'est donc une façon sale de coder...
Tu préferrai utiliser du throw à plus savoir quoi en faire et tout gérer toutes les exceptions dans ton point d'entrée ? Cela résoud pas tous les problèmes, ça complique même beaucoup pour certains traitements...

Edit pour en dessous et expliciter mon message :

[1] si on laisse de côté la cas particulier du code à la frontière entre un module avec exception et un qui ne les gère pas et le code historique bien entendu.

C'est au contraire dans cette optique que je répondais. Comme un autre posteur l'a dit il me semble plus haut les développeurs PHP ne sont pas friands des exceptions et donc quand on développe un module il est préferrable de renvoyer des codes de retours que des exceptions quand on développe des modules.
Personnelement je préfère d'autant plus les codes de retours que c'est la philosophie des OS unix et codes que j'utilise dans mon travail (je suis pas dev web, je n'en fais qu'à mes heures perdues les weekends).

[gl]

L'erreur est innacceptable => return avec un code d'erreur

Si tu ne sais pas quoi faire de l'exception à cet endroit et que tu cherches juste à la faire remonter dans les couches supérieures, pourquoi la catcher et la convertir en code de retour [1] ? Pourquoi ne pas laisser le mécanisme d'exception propager l'erreur jusqu'à une couche qui est capable d'en faire quelque-chose ? c'est bien là le rôle des exceptions.


[1] si on laisse de côté la cas particulier du code à la frontière entre un module avec exception et un qui ne les gère pas et le code historique bien entendu.

[ternel]

Je n'ai jamais compris l'intérêt de finally. Comme en a parlé leternel, le RIIA est fait pour ça. Utiliser les exception sans RIIA, c'est un peu un non-sens.

Ceci dit, PHP est un langage sale, à rustine. Et plutôt que d'avoir une gestion du scope de variables cohérent, un emplâtre finally est rajouté...

Il y a des langages, comme le java, où le destructeur est appelé "plus tard", et oui il n'est pas vraiment possible de le définir.
Du coup, le RIIA y est totalement irréalisable.
Bien plus que l'absence d'héritage multiple, c'est ca qui m'énerve le plus en Java...

[gl]

Il y a des langages, comme le java, où le destructeur est appelé "plus tard", et oui il n'est pas vraiment possible de le définir.
Du coup, le RIIA y est totalement irréalisable.
Bien plus que l'absence d'héritage multiple, c'est ca qui m'énerve le plus en Java...

Java7 introduit le try-with-resource qui couvre partiellement le scope du RAII.
Idem en C# avec le using dont l'utilisation me semble plus large que le try-with-resource.

La différence entre ces mécanismes et le RAII tel que présent en C++ est que le choix d'utiliser ou non ce mécanisme est fait à l'acquisition de la ressource alors qu'en C++ il est fait dans le design de la classe.

[ternel]

J'oubliais ces subtilités, parce que, pour mon plus grand plaisir, je suis actuellement sur un projet développé en java 1.4, sur une JVM personalisé, et que je pleure assez régulièrement de devoir écrire toute les cochoncetés que Java 5 avait supprimé.

[matios]

Dans quelle version de PHP, le bloc finally sera incorporé ?
Dans la dernière version en date (PHP 5.4.6), ce bloc n'est toujours pas accepté.
Avez-vous une idée de sa sortie ?

[transgohan]

Ce commit n'a pas engendré l'annonce (ou le lancement) d'une nouvelle version du langage. Les plus téméraires peuvent compiler la dernière branche du langage à partir de son code source.

Bref Wait & See ou recompiles toi une version en l'incluant.