Re: [SSFR] quel langage ?

[Xavier Gachon <xavier@xxxxxxxxxxxxxxxxxx>]

On Fri, Dec 02, 2005 at 02:15:08PM +0000, Philippe Jacquot wrote:
> >Ces chaînes ne sont pas censées être localisées. Ensuite, chaque
> >solution a ses désavantages. Par exemple, il est plus facile de se
> >tromper sur un nombre, il y a toujours le risque d'utiliser le même
> >nombre pour deux choses différentes, il y a aussi un plus grand
> >risque de conflit dû au fait qu'on ne peut pas mettre d'espace de
> >noms sur un nombre (si besoin est).
>
> Sans nullement vouloir t'insulter, on confinerait pas à la mauvaise foi 
> là ?  :-)

bah il est question d'exceptions non ? un systeme de control de flux
qui vient le plus souvent remplacer une gestion d'erreurs sans aucune
raison valable simplement par ce que les codeurs se refusent a gerer
les erreurs convenablement des la conception de son bout de code
(je passe sur la soi disant reutilisabilité/compatibilité de la
gestion d'erreurs entre modules/dans un modele objet... :).

Resultat des courses ce qui etait des cas d'exceptions devient la
methode pour remonter des erreurs par defaut, sauf que la complexité
de celle-ci dans de nombreux cas devient une geniale source d'erreurs
elle meme. En voulant des codes numeriques pour des raisons d'usages
tu fais un peu la meme erreur %-)

Si les langages populaires proposaient des mecanismes de gestion
d'exceptions plus evolué tel, dans un style fonctionnel, des fonctions
en lieu et place de code numeriques ou de chaines, fonctions premettant
de reprendre l'execution pil poil apres la levée de l'exception (via un
design qu'on appel le Continuation Passing Style), ca ne te viendrais
meme pas a l'idée. Ceci pour illustrer en quoi vouloir un certain type
de valeurs n'est pas vraiment serieux, sans quoi ce "mecanisme" ne fait
pas bon menage avec les langages imperatifs :-)

                                                xavier.

-- 
klapwet 
-- 
pwet 
--