Le code présent dans le "finally" est appelé quoi qu'il se passe, s'il y a eu une exception ou non. C'est pratique pour par exemple les écritures dans les fichiers. Si jamais ton code pète une exception, tu veux quand même fermer ton stream de lecture/écriture du fichier.
Gérer les exceptions dans une application va aussi permettre de créer des logs plus fins et avertir l'administrateur par mail lorsque le site est en production. On peut aussi se créer une class remplaçant l'affichage de xdebug pour afficher plus d'informations ou lorsque celui-ci n'est pas disponible sur le serveur. Dommage que tu n'aies pas parlé de la méthode $e->getTrace() pour récupérer les paramètres envoyés à chaque fonctions. Malgré ça, très bon tuto pour l'introduction aux exceptions !
Encore un bon tuto, merci! Je crois que si une exception est lancée mais pas attrapée faute de catch correspondant à son, type, le finally est exécuté avant que le script ne s'arrête.
Globalement le tuto est plutôt sympas, dommage ce petit couac sur le bloc finally, c'est plus qu'utile lorsqu’on met en place une vrai gestion des exceptions. Comme beaucoup l'ont déjà dit, la première utilisé est de fermer les ressources active indépendamment du statu du block. Alors certes on peux dupliquer les fermeture dans le try et dans le(s) catch, mais dans un soucis de cohérence et de factorisation le block finally trouve toute sa place. Dans le cas ou l'on ne souhaite pas arrêter la propagation d'une exception (erreur bloquante menant a un etat ou l'application ne peux continuer d'exister) on peux utiliser un block try/finally pour gérer les ressources active et terminer l'application proprement. La encore cette syntaxe permet d’éviter de catcher une erreur pour la rethrow juste apres.
Le blocs finally serra appeler dans tout les cas, même si tu fait un "return" dans ton blocs catch. Exemple qui sert a rien : function teste(){ try{ return 50 ; }finally{ return 1 ; } } var a = teste(); // a = 1 , est non 50
J'utilisais le type interface Throwable qui englobe les Error et les Exception... catch (Throwable $e){ switch (get_class($e)){ case "PDOException": die("Erreur de connection dB. message {$e->getCode()}"); break; case "Exception": die("Exception N°{$e->getCode()}: {$e->getMessage()}"); break; case "Error": die("Erreur fatale"); break; default: die("Erreur inconnue."); break; } }
Le code présent dans le "finally" est appelé quoi qu'il se passe, s'il y a eu une exception ou non. C'est pratique pour par exemple les écritures dans les fichiers. Si jamais ton code pète une exception, tu veux quand même fermer ton stream de lecture/écriture du fichier.
Le cours est excellent !!! Merci
Gérer les exceptions dans une application va aussi permettre de créer des logs plus fins et avertir l'administrateur par mail lorsque le site est en production.
On peut aussi se créer une class remplaçant l'affichage de xdebug pour afficher plus d'informations ou lorsque celui-ci n'est pas disponible sur le serveur.
Dommage que tu n'aies pas parlé de la méthode $e->getTrace() pour récupérer les paramètres envoyés à chaque fonctions.
Malgré ça, très bon tuto pour l'introduction aux exceptions !
Génial, merci c'est complètement clair ^_^
Les messages d'exception sont affichés dans les logs ?
Encore un bon tuto, merci!
Je crois que si une exception est lancée mais pas attrapée faute de catch correspondant à son, type, le finally est exécuté avant que le script ne s'arrête.
Globalement le tuto est plutôt sympas, dommage ce petit couac sur le bloc finally, c'est plus qu'utile lorsqu’on met en place une vrai gestion des exceptions. Comme beaucoup l'ont déjà dit, la première utilisé est de fermer les ressources active indépendamment du statu du block. Alors certes on peux dupliquer les fermeture dans le try et dans le(s) catch, mais dans un soucis de cohérence et de factorisation le block finally trouve toute sa place.
Dans le cas ou l'on ne souhaite pas arrêter la propagation d'une exception (erreur bloquante menant a un etat ou l'application ne peux continuer d'exister) on peux utiliser un block try/finally pour gérer les ressources active et terminer l'application proprement. La encore cette syntaxe permet d’éviter de catcher une erreur pour la rethrow juste apres.
Le blocs finally serra appeler dans tout les cas, même si tu fait un "return" dans ton blocs catch.
Exemple qui sert a rien :
function teste(){
try{
return 50 ;
}finally{
return 1 ;
}
}
var a = teste();
// a = 1 , est non 50
J'utilisais le type interface Throwable qui englobe les Error et les Exception...
catch (Throwable $e){
switch (get_class($e)){
case "PDOException":
die("Erreur de connection dB. message {$e->getCode()}");
break;
case "Exception":
die("Exception N°{$e->getCode()}: {$e->getMessage()}");
break;
case "Error":
die("Erreur fatale");
break;
default:
die("Erreur inconnue.");
break;
}
}
moi personnalement j'arrive pas a touver une video qui ma bien expliquer ca je pense j'ai un probleme moi XD
c'est pas clair du tout