Bonjour,

Comment gérer les erreurs dues à la modification de propriétés d'un objet avec de mauvaises valeurs (mauvais état de l'objet) ?

Un exemple étant souvent plus parlant:
Dans un modifieur setNbQuestions($nbQuestions), si je passe en paramètre un string ou un nombre trop grand, comment gérer le mauvais état ?
Pour l'instant si le test du if( is_numeric($nbQuestions) ) ne passe pas, je retourne la valeur NULL.
Mais à l'usage je sens bien que ce n'est pas le mieux.

Comment gérez vous ce problème ?

Merci par avance

salut,

je diras que lever une exception serais le mieux
http://www.php.net/manual/fr/language.exceptions.php

pour le retour false plutôt que null nan ?


@+

Ça m'oblige à faire un try{} catch{} à chaque fois que je créé un objet ou en modifie son état.

Je vais sûrement choisir cette méthode mais essayer de réduire mes tests alors.

Cela dépend de tes besoins mais ton try peut comporter plusieurs conditions :

<?php
$a = 1;
$b = 'a';

try
                {
                        if($a != 1)                                                         
                        throw new Exception('a différent de 1');  
						
			if($b != 'c') 
			throw new Exception('b différent de c');                                        
                }
                                                                                         
        catch(Exception $e)
                         
                {
                        echo $e->getMessage ();
                        exit;
                }    
?>

La méthode vérifie et retourne une exception en cas de problème. Si le problème n'est pas prévisible, pas besoin de try catch puisque c'est un problème lors de la conception du site/application (par exemple, transmettre un string au lieu d'un integer). Si il est prévisible (c-a-d potentiellement amené à échouer), tu dois mettre un try catch.

Par exemple

try {
MailSender::send('[email protected]','for u', 'a message');
} catch (....

L'envoie d'un email est potentiellement amené à échouer. A partir de là, tu peux alors réessayer l'envoi, et/ou dire à l'utilisateur que ça n'a pas marché, logguer un message, et lui conseiller de réessayer ultérieurement.

Si, par contre, le problème n'est pas censé arrivé si tu respectes tes classes, tu seras vite au courant et voilà, tu pourras le résoudre.

Attention, cela ne veut pas dire que jamais une exception ne sera émise dans ce dernier cas, mais - à mon sens - juste que, d'une certaines façons, si elles arrivent, c'est que "rien ne va plus", et/ou que de toutes façons tu ne peux rien proposer à l'utilisateur. Donc, prévoir un récepteur d'exceptions non capturées pour afficher un joli et respectueux messages à l'utilisateur, et logguer l'erreur pour voir agir vite et, surtout, le savoir.

Perso, pour la connexion et les échanges avec la base de données, je pars du principe que ce n'est pas censé echouer, tout simplement parce que je ne vais pas tester chaque requête que je fais, non seulement parce que ce serait énorme, mais en plus parce que ça me ferait une belle jambe. Un message poli est alors affiché à l'utilisateur lui demandant de réessayer ultérieurement et je loggue le message pour intervenir (mais si c'est un problème temporaire de réseau loopback ou de disponibilité serveur, je ne vois pas ce que l'on peut faire de mieux que d'afficher un message d'erreur général ...), alors qu'une fonction qui va vraiment faire des opérations réseaux à risque doit être contrôlé, puisque l'on peut quand même proposer une alternative, réessayer, etc.

Bref, ça reste deux choses différentes, le quand/ou émettre une exception, et le quand/ou l'attraper. Tu l'attrapes là où il te semble que c'est le plus adapté ... C'est aussi une question de responsabilité, et pour quelque chose d'aussi global que la base de données, ce n'est pas de la responsabilité individuelle des classes qui utilisent la base de données pour travailler sur le métier, mais plutôt à l'arrière.

Voilà En tous cas, concernant le retour NULL, c'est typique de PHP, mais si tu te fixes comme règle (que j'aime), qu'une fonction ne peut retourner qu'un et un seul type de valeur, Null n'est possible que dans certains cas où aucune valeur n'est retournée (fonction sans retour) ou aucun objet retourné (instance retournée, mais pour raison x ou y il peut ne pas y en avoir), mais pas pour une erreur.