Une macro ne pourra jamais remplacer un traitement intelligent d'une erreur. Le fait est que le traitement intelligent et correct d'une erreur est quelque chose de complexe (donc difficile à faire bien), coûteux en temps de dev, mais en même temps, indispensable dès qu'on arrive sur des gros logiciels.
Joel On Software y consacre un article pas trop mal d'ailleurs, que j'ai la flemme de retrouver.
Exception exhaustif à la java (je déclare tout ce que je lève), laxiste à la python (chaque ligne de code peut me balancer 24 exceptions différentes) ou code de libération en C avec des goto, aucune méthode n'est parfaite mais ce qui est sur, c'est que ça demande de l'investissement.
Suivant la taille du logiciel et son utilité, cet investissement est à mon sens pas toujours justifié.
Pour élargir le débat:
On peut aussi prendre le cas d'erreur du disque plein, ou du logiciel qui s'execute sur une partition sans les droits d'écritures. C'est des cas réels, compliqués à gérer, dans lesquels il faut informer l'utilisateur pour qu'il resolve intélligemment son problème. Dans ces deux cas, un simple crash est une mauvaise porte de sortie car l'utilisateur doit être informé de la situation pour pouvoir la régler.
Sinon le nouveau langage Go introduit un truc intéressant: des routines qui sont exécutées à la sortie de la fonction, dans l'ordre inverse où elles sont été déclarées. La logique est bien de mettre toute la libération des ressources dans ces routines, de façon à ce qu'elles soit libérées automatiquement en cas d'erreur.
Mais là encore, d'une part il faut être très rigoureux et d'autre part, il y a des fois où la libération de ressource est compliquée et même avec toute la structure du langage, on ne peut pas se passer d'une bonne prise de tête pour traiter avec honneur tous les cas tordus.
[^] # Re: Je pense que tu confonds les cas où c'est nécessaire
Posté par Philippe F (site web personnel) . En réponse au journal Genèse d'un journal. Évalué à 4.
Une macro ne pourra jamais remplacer un traitement intelligent d'une erreur. Le fait est que le traitement intelligent et correct d'une erreur est quelque chose de complexe (donc difficile à faire bien), coûteux en temps de dev, mais en même temps, indispensable dès qu'on arrive sur des gros logiciels.
Joel On Software y consacre un article pas trop mal d'ailleurs, que j'ai la flemme de retrouver.
Exception exhaustif à la java (je déclare tout ce que je lève), laxiste à la python (chaque ligne de code peut me balancer 24 exceptions différentes) ou code de libération en C avec des goto, aucune méthode n'est parfaite mais ce qui est sur, c'est que ça demande de l'investissement.
Suivant la taille du logiciel et son utilité, cet investissement est à mon sens pas toujours justifié.
Pour élargir le débat:
On peut aussi prendre le cas d'erreur du disque plein, ou du logiciel qui s'execute sur une partition sans les droits d'écritures. C'est des cas réels, compliqués à gérer, dans lesquels il faut informer l'utilisateur pour qu'il resolve intélligemment son problème. Dans ces deux cas, un simple crash est une mauvaise porte de sortie car l'utilisateur doit être informé de la situation pour pouvoir la régler.
Sinon le nouveau langage Go introduit un truc intéressant: des routines qui sont exécutées à la sortie de la fonction, dans l'ordre inverse où elles sont été déclarées. La logique est bien de mettre toute la libération des ressources dans ces routines, de façon à ce qu'elles soit libérées automatiquement en cas d'erreur.
Mais là encore, d'une part il faut être très rigoureux et d'autre part, il y a des fois où la libération de ressource est compliquée et même avec toute la structure du langage, on ne peut pas se passer d'une bonne prise de tête pour traiter avec honneur tous les cas tordus.