| | auteur : wamania |
Je vois principalement deux situations dans laquelle les
exceptions sont essentielles.
-
Dans le cas d'une méthode critique, comme les accès
aux bases de données ou aux fichiers ;
-
Pour augmenter la lisibilité, en remplaçant les
cascades de :
if (a == 'ok')
{
if (b == 'ok')
{
}
else
{
echo 'b pas OK';
}
}
else
{
echo 'a pas OK';
} |
par
try
{
if (a!='OK') { throw new Exception('a pas OK'); }
if (b!='OK') { throw new Exception('b pas OK'); }
}
catch (Exception $myException)
{
echo $myException->getMessage();
} |
|
lien :  Tutoriel : Exceptions et PHP5, par Guillaume Affringue
|
| | auteur : wamania |
Non !
Les exceptions offrent des fonctionnalités supplémentaires,
mais aux dépens des performances principalement et, dans
certains cas, de la lisibilité.
Il faut savoir que lorsqu'une exception est soulevée,
l'ensemble du contexte du bloc try est stocké en mémoire,
et qu'il est possible d'imbriquer indéfiniment les blocs try
les uns dans les autres.
Niveau visibilité, il suffit d'imaginer un process un peu
complexe, faisant appel à diverses extensions, accès à une
base de données, à des fichiers, etc. À terme, on
arrive à 150 lignes de :
catch (ClassXException $myexceptionX)
{
} |
|
lien : Tutoriel : Exceptions et PHP5, par Guillaume Affringue
|
| | auteur : wamania |
Une seule bonne réponse : une classe par fonctionnalité.
C'est pourquoi beaucoup d'extensions définissent leur propre
classe d'exception (DOMException, SQLiteException, etc.).
Il est ainsi fréquent d'avoir des cascades de blocs catch pour
attraper chacune des exceptions susceptibles d'être levées.
On peut ainsi définir une classe pour l'accès à base de données,
une classe pour les accès fichier, une classe pour
les erreurs PHP, une classe pour les "erreurs" utilisateurs,
etc.
Outre l'intérêt de pouvoir appliquer un traitement spécifique
en fonction de l'origine de l'exception, le fait de définir
une classe adaptée pour chaque fonctionnalité permet de ne
pas tomber dans le piège consistant à reproduire dans le
traitement d'une exception le problème qui avait soulevé
cette exception.
Par exemple, on tâchera de ne pas écrire de log dans une base
de donnée lorsqu'une exception est soulevée lors d'un échec
de connexion à cette base de donnée.
|
lien : Tutoriel : Exceptions et PHP5, par Guillaume Affringue
|
| | auteur : wamania |
Oui, en écrivant sa propre classe d'exception héritant de la
classe Exception définie par PHP.
Pour cela, on déclare une classe selon ce modèle :
class MyException extends Exception
{
public function __construct($message, $code)
{
parent::__construct($message, $code);
}
public function MyLog()
{
}
} |
Utilisation :
try
{
throw new MyException('ceci est MON exception');
}
catch (MyException $myException)
{
$myException->MyLog();
echo $myException->getMessage();
} |
|
lien : Tutoriel : Exceptions et PHP5, par Guillaume Affringue
|
| | auteur : wamania |
Il s'agit de la classe d'exception proposée par PHP.
Elle définit 4 attributs protected :
-
$message : Le message passé par la syntaxe
"throw new Exception($message)" ;
-
$code : Un code que l'on peut passer en
second argument (facultatif)
"throw new Exception($message, $code)", ce code ne
représente rien pour PHP, il existe uniquement pour
que vous puissiez définir votre propre système de
code ;
-
$file : Le fichier dans lequel l'exception
est soulevée ;
-
$line : La ligne à laquelle l'exception est
soulevée.
Elle définit également 6 méthodes permettant de récupérer
les 4 attributs ci-dessus, ainsi que les "traces" au format
array ou string :
-
final function getMessage(); // message de l'exception
-
final function getCode(); // code de l'exception
-
final function getFile(); // nom du fichier source
-
final function getLine(); // ligne du fichier source
-
final function getTrace(); // un tableau de backtrace()
-
final function getTraceAsString(); // chaîne formatée
de trace
|
lien : Tutoriel : Exceptions et PHP5, par Guillaume Affringue
|
| | auteur : wamania |
PHP5 n'a pas réinventé la roue. La syntaxe est identique aux
autres langages possédant un mécanisme d'exceptions, mais ne
possède pas la propriété finalize comme certains langages.
Voici un exemple simple d'utilisation des exceptions :
try
{
$resource = mysql_connect('host', 'login', 'password');
if(empty($resource))
{
throw new Exception('Impossible de se connecter à MySQL');
}
}
catch(Exception $myException)
{
echo 'Erreur : '.$myException->getMessage();
} |
|
lien : Tutoriel : Exceptions et PHP5, par Guillaume Affringue
|
| | auteur : wamania |
Les exceptions, comme leur nom l'indique, servent à traiter
les cas exceptionnels que nous pourrions rencontrer. Ceci
peut comprendre les erreurs générées par PHP, mais pas
seulement. En effet, c'est le développeur qui décide ce qui
est ou n'est pas exceptionnel.
Voici quelques cas dans lesquels les exceptions peuvent être
utilisés :
- Problème d'ouverture d'une base de données ;
- Problème d'ouverture d'un fichier texte ;
- Problème de parsing de fichier XML ;
- Erreur de saisie par un utilisateur.
Il n'y a aucune limite, mais seuls les points sensibles ont
vraiment besoin d'être gérés par les exceptions.
Le point essentiel à retenir est qu'une exception n'existe
que parce que le développeur l'a décidé, contrairement aux
erreurs.
|
lien : Tutoriel : Exceptions et PHP5, par Guillaume Affringue
|
Consultez les autres F.A.Q's
Les sources présentés sur cette pages sont libre de droits,
et vous pouvez les utiliser à votre convenance. Par contre cette page de présentation de ces sources constitue une oeuvre intellectuelle protégée par les droits d'auteurs.
Copyright ©2003
Developpez LLC. Tout droits réservés Developpez LLC.
Aucune reproduction, même partielle, ne peut être faite de ce site et de
l'ensemble de son contenu : textes, documents et images sans l'autorisation
expresse de Developpez LLC. Sinon vous encourez selon la loi jusqu'à 3 ans
de prison et jusqu'à 300 000 E de dommages et intérets.
Cette page est déposée à la SACD.
|
