dolibarr-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Dolibarr-dev] Utilisation de Dolibarr_print_error


From: Benoit Mortier
Subject: Re: [Dolibarr-dev] Utilisation de Dolibarr_print_error
Date: Sun, 19 Sep 2004 17:53:40 +0200
User-agent: KMail/1.6.2

Le mercredi 15 Septembre 2004 10:15, Rodolphe Quiedeville a écrit :
> Eldy wrote:
> > Rodolphe Quiedeville wrote:
> >
> >
> > La finalité présentie de dolibarr_print_error est d'afficher des infos
> > dans le cas d'une erreur technique grave qui n'est pas sensée arriver
> > (en général cela veut dire bug dans dolibarr, le plus souvent suite à
> > une requete mal générée à cause d'absence de controle des paramètres).
> > De part cette vocation, j'utilisais jusqu'ici la fonction à tous les
> > endroits du code (écran ou script) car quand cela arrive, le plus
> > souvent rien ne saire de continuer.
> > Une solution serait d'avoir 2 fonctions. Une pour les classes et une
> > pour les écrans mais cela complique le codage car en cas d'erreur sur
> > la fonction pour les classes en mode web, le retour (copie écran de
> > l'utilisateur qui a buggué) ne sera pas aussi complet ou ne pas la
> > mettre dans les classes, mais l'expérience à montré que les lacunes
> > étaient avant tout dans le code des classes car c'est lui qui génère
> > les requetes.
> >
> > Aussi je propose une autre alternative: En cas d'appel depuis un
> > script, on pourrait détecter au sein de la fonction que l'on est en
> > mode script (La variable DOCUMENT_ROOT n'est alors pas définie) pour
> > afficher un affichage non web (avec de retours à la ligne de type \n
> > plutot que < br
> >
> >  > et ne pas mettre les infos propres au web (comme l'url appelante),
> >  > on
> >
> > pourrait même y mettre des infos propres au script comme l'ID de
> > process et le PID. Cela permet d'avoir une fonction générique
> > utilisable partout avec un résultat élégant dans les 2 cas.
>
> Salut,
>
> Pour moi les classes doivent renvoyer une erreur simple et ensuite
> l'affichage appel la fonction dolibarr_print_error, en fait la gestion
> des erreurs est un point faible de Dolibarr depuis le début je le
> reconnais aisément, il faudrait que l'on se définisse un standard pour
> cela.

cela semble bien en effet les classes renvoient un code numerique si le code 
d'erreur ets superieur a 0, ce code est passe a dolibarr_print_error

> Je propose que chaque appel à une fonction de classe renvoie 1 en cas de
>   succès et 0 dans le cas contaire, si on renvoie 0 alors on positionne
> la propriété de la class error_number par exemple, il faudra être trés
> soigneux car pour l'instant suivant les classes on renvoie 0 ou 1 en cas
> d'erreur (bouh c'est mal).
>
> Que pensez-vous de cette solution ?

je propose de rester dans la logique unix, 0 = reussite, 1 = echec, ce qui 
pourrait permettre de raffiner les codes d'erreur au fur et a mesure...
 
A+
-- 
Benoit Mortier
OpenSides sprl
Linux Engineer




reply via email to

[Prev in Thread] Current Thread [Next in Thread]