Re: classe de gestion des erreurs

Eric Daspet wrote:

>Gregoire Cachet wrote:
>  
>
>>la gestion des erreurs, parlons-en !
>>    
>>
>
>  
>
>>1/ un niveau module : s'il y a un problème dans un module, ca affiche 
>>l'erreur à l'emplacement du module, mais on conserve le reste de la 
>>donnée. En gros, si l'article déconne, on garde le menu et le titre de 
>>la page par exemple et on affiche l'erreur à l'emplacement de l'article.
>>    
>>
>
>Ca je suis plutot contre. C'est la philosophie initiale de PHP et elle 
>est selon moi mauvaise. Si il y a un problème interne on renvoie une 
>exception. Charge au soft de savoir gérer cette exception ou pas. Au 
>pire on lance une erreur 500 mais l'utilisateur ne sera de toutes façons 
>jamais plus avancé avec un texte d'erreur à la place de l'article.
>
>  
>
ok !

>  
>
>>2/ un niveau global de la page : s'il y a un pb un peu plus important 
>>(pas les droits d'acceder a la donnée, etc ...)
>>3/ un niveau pour les cas de crise.
>>
>>le niveau 1/ et 2/ respecteraient le type de donnée que demande 
>>l'utilisateur (XHTML, PDF ...) alors que le niveau 3/ renverait du texte 
>>pur. En gros, on utilise le niveau 3/ si on arrive pas a formatter la sortie
>>
>>Vous avez des idées la dessus ?
>>    
>>
>
>À mon avis il vaut mieux garder un seul niveau d'erreur : ca marche ou 
>ça ne marche pas. Quand ça ne marche pas on génère l'erreur HTTP adéquate.
>Rien n'empêche par contre que ton erreur HTTP ai un contenu en PDF si 
>c'est un pdf qui a été demandé, mais ce seront les modules de 
>transformation et d'envoi qui décideront ça, pas celui de stockage qui 
>est censé renvoyer l'erreur.
>
>  
>
j'y connais strictement rien en HTTP ... Je vais avoir du mal a 
implanter ... Quelqu'un s'en charge ?


-- 
Grégoire Cachet - Développeur intégrateur chez Audacy
http://www.zwiffer.org           http://www.audacy.fr