Conversation
precedente ou
suivante
habitudes de programmation
Envoyé par:
alexkid
Bonjour,
J'ai changé mes habitudes de programmation sans m'apercevoir. En fait à chaque fois que je lance une fonction f, je teste ce qu'elle retourne et si elle retourne une erreur je quite proprement le programme. Mais voilà, je me rends compte que ça deviens un peu lourd à lire, exemple :
if(!(XCopyArea( blabla ))) {
perror("blabla");
close(blabla);
fclose(blabla);
}
if(!(XCopyArea( blabla ))) {
perror("blabla");
close(blabla);
fclose(blabla);
}
if(id_file == -1) {
perror("blabla");
close(blabla);
fclose(blabla);
}
...
Voilà, du coup mes programmes deviennent super longs, je me demande si je ne fais pas fausse route ? Bientôt je vais me mettre à tester la variable errno à chaque ligne écrite.
Merci d'avance
J'ai changé mes habitudes de programmation sans m'apercevoir. En fait à chaque fois que je lance une fonction f, je teste ce qu'elle retourne et si elle retourne une erreur je quite proprement le programme. Mais voilà, je me rends compte que ça deviens un peu lourd à lire, exemple :
if(!(XCopyArea( blabla ))) {
perror("blabla");
close(blabla);
fclose(blabla);
}
if(!(XCopyArea( blabla ))) {
perror("blabla");
close(blabla);
fclose(blabla);
}
if(id_file == -1) {
perror("blabla");
close(blabla);
fclose(blabla);
}
...
Voilà, du coup mes programmes deviennent super longs, je me demande si je ne fais pas fausse route ? Bientôt je vais me mettre à tester la variable errno à chaque ligne écrite.
Merci d'avance
Poste le Sunday 17 June 2007 21:16:38
Re: habitudes de programmation
Envoyé par:
Fanch
Non tu as raison, c'est bien ce qu'il faut faire : tout appel critique doit faire l'objet d'un traitement d'erreur et quoi qu'il en soit d'une ligne de log (potentiellement désactivable).
En revanche, ta façon de procéder est lourde. Chacun fait un peu comme il veut, mais une maniere plus pratique (àmha) de faire est la suivante :
Bien sûr ça n'est qu'un exemple, tu peux créer plusieurs macros de contrôle de lignes (notamment pour automatiser les logs).
Voilà ; au passage, c'est la seule et unique façon d'utiliser proprement l'instruction goto.
L'inconvénient de ce système est qu'il devient vite difficile à debugger (à cause des macros) ; il implique donc d'avoir des logs impeccables ...
Have fun !
------- <br />
La meilleure façon de prédire le futur, c'est de l'inventer ~ Alan Kay
En revanche, ta façon de procéder est lourde. Chacun fait un peu comme il veut, mais une maniere plus pratique (àmha) de faire est la suivante :
#define CHECKED_CALL(fct, error_cond, lbl) if ( fct error_cond ) goto lbl
...
CHECKED_CALL( XCopyArea( blabla ), == 0, Err_maFonction) ;
...
Err_maFonction:;
perror("blabla");
close(blabla);
fclose(blabla);
...
Bien sûr ça n'est qu'un exemple, tu peux créer plusieurs macros de contrôle de lignes (notamment pour automatiser les logs).
Voilà ; au passage, c'est la seule et unique façon d'utiliser proprement l'instruction goto.
L'inconvénient de ce système est qu'il devient vite difficile à debugger (à cause des macros) ; il implique donc d'avoir des logs impeccables ...
Have fun !
------- <br />
La meilleure façon de prédire le futur, c'est de l'inventer ~ Alan Kay
Poste le Monday 18 June 2007 09:06:28
Re: habitudes de programmation
Envoyé par:
Calou
Salut,
Gerer les erreurs de ces appels a fonction est le minimum que tu puisses faire.
Dans ton exemple, c'est encore plus parlant. Oublier de fermer proprement le fichier que tu as ouvert est aussi bete que de faire une voiture sans frein.
Pour l'écriture, c'est du cas par cas, ca dépend de ton niveau d'appel, de ce que tu as a faire dans le cas ou ca se passe bien ou du nombre d'erreurs possibles.
L'idee des macros est assez sypathique, mais j'aime pas trop (meme si il y a la maniere dans ce que tu presentes).
En général, je prefere traiter l'erreur dans le else... (mais bon c'est du cas par cas)
Gerer les erreurs de ces appels a fonction est le minimum que tu puisses faire.
Dans ton exemple, c'est encore plus parlant. Oublier de fermer proprement le fichier que tu as ouvert est aussi bete que de faire une voiture sans frein.
Pour l'écriture, c'est du cas par cas, ca dépend de ton niveau d'appel, de ce que tu as a faire dans le cas ou ca se passe bien ou du nombre d'erreurs possibles.
L'idee des macros est assez sypathique, mais j'aime pas trop (meme si il y a la maniere dans ce que tu presentes).
En général, je prefere traiter l'erreur dans le else... (mais bon c'est du cas par cas)
Poste le Monday 18 June 2007 16:20:29
Re: habitudes de programmation
Envoyé par:
alexkid
Bonjour,
Merci pour vos réponses. En fait, dans des bouqins de programmation écrits par des profs qui maîtrisent, ils ne font pas comme cela, ils écrivent très légèrement. Et puis dans certains codes source c'est pareil. C'est pour ça que j'étais un peu désorienté.
à plus.
Merci pour vos réponses. En fait, dans des bouqins de programmation écrits par des profs qui maîtrisent, ils ne font pas comme cela, ils écrivent très légèrement. Et puis dans certains codes source c'est pareil. C'est pour ça que j'étais un peu désorienté.
à plus.
Poste le Wednesday 20 June 2007 08:54:30
Re: habitudes de programmation
Envoyé par:
Fanch
Dans les bouquins c'est normal qu'il n'y ait pas de traitement d'erreur aussi lourd que dans la vie réelle : ces traitements rendraient les listing illisible sur papier et n'ont aucun intérêt (à priori) par rapport à ce qu'illustre ledit listing.
Dans certains sources, c'est déjà moins normal bien que certains appels ne nécessitent aucun contrôle.
------- <br />
La meilleure façon de prédire le futur, c'est de l'inventer ~ Alan Kay
Dans certains sources, c'est déjà moins normal bien que certains appels ne nécessitent aucun contrôle.
------- <br />
La meilleure façon de prédire le futur, c'est de l'inventer ~ Alan Kay
Poste le Wednesday 20 June 2007 09:15:55
Ce forum !
habitudes de programmation
Pour poser vos questions sur les scripts shell, le Perl, le C, etc... Attention : nous ne sommes pas des spécialistes du dev, ce forum est juste pour de petites aides ponctuelles concernant le développement et les outils de développement.
Sauf mention contraire, les documentations publiées sont sous licence Creative-Commons