achevant l'écriture de ma bibliothèque servant à utiliser l'API DirectShow,
j'en arrive au sujet un peu brulant pour moi que sont les exceptions...
Je ne sais pas comment les implémenter correctement.
J'ai distingué trois types d'exception qui peuvent être levées:
1) Les exceptions qui surgissent pendant l'initialisation des modules et
qui interdisent l'utilisation du module (initialisation d'un filtre qui
échoue par exemple, ou bien tentative de connecter deux filtres qui ne
peuvent pas être mis en relation ensemble)
2) Les exceptions qui surgissent lors de l'utilisation d'un module, mais
qui n'entravent pas son fonctionnement (impossibilité de se déplacer dans
une vidéo manuellement par exemple, impossibilité d'extraire une image
d'une vidéo)
3) Les exceptions qui sont levées suite à une action de l'utilisateur du
programme final (Problème dans le choix d'un fichier par exemple (un ZIP au
lieu d'un AVI))
Les exceptions de la première catégorie sont plutôt destinés au programmeur
qui utilise la bibliothèque et n'aident en rien l'utilisateur du programme
final, puisqu'il ne pourra rien modifier.
Les exceptions de la deuxième catégorie peuvent être utiles à l'utilisateur
de la librairie et à l'utilisateur du programme
Enfin les exceptions de la dernière catégorie sont exclusivement destinées
à l'utilisateur du programme, afin qu'il change de fichier qui doit être lu
par exemple.
Bref toujours est-il que je ne sais pas comment m'y prendre...
Est-ce que je dois encadrer les fonctions susceptibles de lever une
exception par un try catch()? Lesquelles?
Est-ce à l'utilisateur de la bibiliothèque de le faire?
L'utilisateur du programme?
Ou bien je laisse les exceptions se déclencher et c'est au programmeur de
se débrouiller comme il veut?
| La lisibilité est une condition nécessaire mais non suffisante | de la correction.
En réalité, les deux sont orthogonales.
Absolument pas. Un code qui n'est pas lisible n'est pas correct. Par définition : un code n'est correct que si on peut démontrer qu'il remplit son contrat. Or, pour démontrer quoique ce soit du code, il faut pouvoir le comprendre.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Gabriel Dos Reis wrote:
"kanze" <kanze@gabi-soft.fr> writes:
[...]
| La lisibilité est une condition nécessaire mais non suffisante
| de la correction.
En réalité, les deux sont orthogonales.
Absolument pas. Un code qui n'est pas lisible n'est pas correct.
Par définition : un code n'est correct que si on peut démontrer
qu'il remplit son contrat. Or, pour démontrer quoique ce soit du
code, il faut pouvoir le comprendre.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
| La lisibilité est une condition nécessaire mais non suffisante | de la correction.
En réalité, les deux sont orthogonales.
Absolument pas. Un code qui n'est pas lisible n'est pas correct. Par définition : un code n'est correct que si on peut démontrer qu'il remplit son contrat. Or, pour démontrer quoique ce soit du code, il faut pouvoir le comprendre.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
kanze
Fabien LE LEZ wrote:
[...]
Pour résumer, j'ai l'impression que les exceptions conviennent bien dans le cas où on a beaucoup de "throw" et très peu de "try...catch".
En effet, c'est aussi un paramètre à prendre en considération.
Tu as écrit par ailleurs :
[Les exceptions] nuisent, en revanche, en ce qu'elles introduisent des flux de contrôle invisible, qui peuvent parfois surprendre.
Certes. Mais les exceptions existent ; même si tu n'en lances jamais toi-même, il y a toujours le risque que telle ou telle fonction en lance une.
C'est effectivement un point important. Une partie du « coût » des exceptions est un « one time cost » : tu le paies dès qu'il y a des exceptions dans le programme, et le coût incrémental d'ajouter une exception en plus est beaucoup plus faible.
(En pratique, je considère qu'en général, seuls l'affectation de types de base (et surtout de pointeurs), ainsi que les destructeurs, ont la garantie "nothrow".)
En général, peut-être. À condition d'ajouter les autres fonctions qui présentent la garantie, du genre std::vector<>::swap.
Il faut dire que je travaille beaucoup dans des logiciels d'assez bas niveau. Ce qui veut dire que des opérations avec une garantie nothrow sont beaucoup plus fréquente ; je manipule assez souvent des types de base dans mon code. Du coup, j'ai souvent des cas où je sais qu'il n'y aurait pas d'exception. Au niveau applicatif, ces cas-là sont bien moins fréquents.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Fabien LE LEZ wrote:
[...]
Pour résumer, j'ai l'impression que les exceptions conviennent
bien dans le cas où on a beaucoup de "throw" et très peu de
"try...catch".
En effet, c'est aussi un paramètre à prendre en considération.
Tu as écrit par ailleurs :
[Les exceptions] nuisent, en revanche, en ce qu'elles
introduisent des flux de contrôle invisible, qui peuvent parfois
surprendre.
Certes. Mais les exceptions existent ; même si tu n'en lances
jamais toi-même, il y a toujours le risque que telle ou telle
fonction en lance une.
C'est effectivement un point important. Une partie du « coût »
des exceptions est un « one time cost » : tu le paies dès
qu'il y a des exceptions dans le programme, et le coût
incrémental d'ajouter une exception en plus est beaucoup plus
faible.
(En pratique, je considère qu'en général, seuls l'affectation
de types de base (et surtout de pointeurs), ainsi que les
destructeurs, ont la garantie "nothrow".)
En général, peut-être. À condition d'ajouter les autres
fonctions qui présentent la garantie, du genre
std::vector<>::swap.
Il faut dire que je travaille beaucoup dans des logiciels
d'assez bas niveau. Ce qui veut dire que des opérations avec une
garantie nothrow sont beaucoup plus fréquente ; je manipule
assez souvent des types de base dans mon code. Du coup, j'ai
souvent des cas où je sais qu'il n'y aurait pas d'exception. Au
niveau applicatif, ces cas-là sont bien moins fréquents.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Pour résumer, j'ai l'impression que les exceptions conviennent bien dans le cas où on a beaucoup de "throw" et très peu de "try...catch".
En effet, c'est aussi un paramètre à prendre en considération.
Tu as écrit par ailleurs :
[Les exceptions] nuisent, en revanche, en ce qu'elles introduisent des flux de contrôle invisible, qui peuvent parfois surprendre.
Certes. Mais les exceptions existent ; même si tu n'en lances jamais toi-même, il y a toujours le risque que telle ou telle fonction en lance une.
C'est effectivement un point important. Une partie du « coût » des exceptions est un « one time cost » : tu le paies dès qu'il y a des exceptions dans le programme, et le coût incrémental d'ajouter une exception en plus est beaucoup plus faible.
(En pratique, je considère qu'en général, seuls l'affectation de types de base (et surtout de pointeurs), ainsi que les destructeurs, ont la garantie "nothrow".)
En général, peut-être. À condition d'ajouter les autres fonctions qui présentent la garantie, du genre std::vector<>::swap.
Il faut dire que je travaille beaucoup dans des logiciels d'assez bas niveau. Ce qui veut dire que des opérations avec une garantie nothrow sont beaucoup plus fréquente ; je manipule assez souvent des types de base dans mon code. Du coup, j'ai souvent des cas où je sais qu'il n'y aurait pas d'exception. Au niveau applicatif, ces cas-là sont bien moins fréquents.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Gabriel Dos Reis
"kanze" writes:
| Gabriel Dos Reis wrote: | > "kanze" writes: | | > [...] | | > | La seule chose à ajouter, c'est que si tu écris une | > | bibliothèque, et tu ne sais pas trop où le client va traiter | > | l'erreur, il vaut mieux pécher du côté du code de retour. | > | Simplement parce que c'est beaucoup plus facile au client | > | d'écrire : | > | if ( f() != OK ) throw whatever ; | > | que d'écrire : | > | | > | try { | > | f() ; | > | } catch ( Whatever& error ) { | > | // ... | > | } | | > Je driais exactement l'opposé. | | Que c'est plus facile d'écrire cinq lignes, en ouvrant des blocs | de scope supplémentaire pour l'appel, que de n'en écrire | qu'une ?
Si la question est de compter le nombre de caractères écrits, il est beaucoup plus facile de ne pas en écrire du tout.
Si la question est d'écrire du code bibliothèque simple exprimant directement l'algorithme utilisé et qui marche, je maintiens mon affirmation.
-- Gaby
"kanze" <kanze@gabi-soft.fr> writes:
| Gabriel Dos Reis wrote:
| > "kanze" <kanze@gabi-soft.fr> writes:
|
| > [...]
|
| > | La seule chose à ajouter, c'est que si tu écris une
| > | bibliothèque, et tu ne sais pas trop où le client va traiter
| > | l'erreur, il vaut mieux pécher du côté du code de retour.
| > | Simplement parce que c'est beaucoup plus facile au client
| > | d'écrire :
| > | if ( f() != OK ) throw whatever ;
| > | que d'écrire :
| > |
| > | try {
| > | f() ;
| > | } catch ( Whatever& error ) {
| > | // ...
| > | }
|
| > Je driais exactement l'opposé.
|
| Que c'est plus facile d'écrire cinq lignes, en ouvrant des blocs
| de scope supplémentaire pour l'appel, que de n'en écrire
| qu'une ?
Si la question est de compter le nombre de caractères écrits, il est
beaucoup plus facile de ne pas en écrire du tout.
Si la question est d'écrire du code bibliothèque simple exprimant
directement l'algorithme utilisé et qui marche, je maintiens mon affirmation.
| Gabriel Dos Reis wrote: | > "kanze" writes: | | > [...] | | > | La seule chose à ajouter, c'est que si tu écris une | > | bibliothèque, et tu ne sais pas trop où le client va traiter | > | l'erreur, il vaut mieux pécher du côté du code de retour. | > | Simplement parce que c'est beaucoup plus facile au client | > | d'écrire : | > | if ( f() != OK ) throw whatever ; | > | que d'écrire : | > | | > | try { | > | f() ; | > | } catch ( Whatever& error ) { | > | // ... | > | } | | > Je driais exactement l'opposé. | | Que c'est plus facile d'écrire cinq lignes, en ouvrant des blocs | de scope supplémentaire pour l'appel, que de n'en écrire | qu'une ?
Si la question est de compter le nombre de caractères écrits, il est beaucoup plus facile de ne pas en écrire du tout.
Si la question est d'écrire du code bibliothèque simple exprimant directement l'algorithme utilisé et qui marche, je maintiens mon affirmation.
-- Gaby
Gabriel Dos Reis
"kanze" writes:
| Gabriel Dos Reis wrote: | > "kanze" writes: | | [...] | > | La lisibilité est une condition nécessaire mais non suffisante | > | de la correction. | | > En réalité, les deux sont orthogonales. | | Absolument pas. Un code qui n'est pas lisible n'est pas correct.
Ça c'est la théologie selon St James.
Pour la réalité, je suppose que tu as déjà entendu parler de code généré automatiquement par des programmes. Pour la plus grande majorité, ils sont illisibles. Leurs corrections sont souvent démontrées à un niveau plus élévé où les algorithmes utilisés sont exprimés ainsi que les chaînes d'inférence logiques utilisées.
-- Gaby
"kanze" <kanze@gabi-soft.fr> writes:
| Gabriel Dos Reis wrote:
| > "kanze" <kanze@gabi-soft.fr> writes:
|
| [...]
| > | La lisibilité est une condition nécessaire mais non suffisante
| > | de la correction.
|
| > En réalité, les deux sont orthogonales.
|
| Absolument pas. Un code qui n'est pas lisible n'est pas correct.
Ça c'est la théologie selon St James.
Pour la réalité, je suppose que tu as déjà entendu parler de code généré
automatiquement par des programmes. Pour la plus grande majorité, ils
sont illisibles. Leurs corrections sont souvent démontrées à un
niveau plus élévé où les algorithmes utilisés sont exprimés ainsi
que les chaînes d'inférence logiques utilisées.
| Gabriel Dos Reis wrote: | > "kanze" writes: | | [...] | > | La lisibilité est une condition nécessaire mais non suffisante | > | de la correction. | | > En réalité, les deux sont orthogonales. | | Absolument pas. Un code qui n'est pas lisible n'est pas correct.
Ça c'est la théologie selon St James.
Pour la réalité, je suppose que tu as déjà entendu parler de code généré automatiquement par des programmes. Pour la plus grande majorité, ils sont illisibles. Leurs corrections sont souvent démontrées à un niveau plus élévé où les algorithmes utilisés sont exprimés ainsi que les chaînes d'inférence logiques utilisées.
-- Gaby
Michel Decima
"kanze" writes:
| Gabriel Dos Reis wrote: | > "kanze" writes: | | [...] | > | La lisibilité est une condition nécessaire mais non suffisante | > | de la correction. | | > En réalité, les deux sont orthogonales. | | Absolument pas. Un code qui n'est pas lisible n'est pas correct.
Ça c'est la théologie selon St James.
Pour la réalité, je suppose que tu as déjà entendu parler de code généré automatiquement par des programmes. Pour la plus grande majorité, ils sont illisibles. Leurs corrections sont souvent démontrées à un niveau plus élévé où les algorithmes utilisés sont exprimés ainsi que les chaînes d'inférence logiques utilisées.
J'acquiesce concernant du code genéré automatiquement par un autre programme. Par contre, si le code a été généré par un humain, je serais de l'avis de James (peut etre parce que je vois beaucoup de code illisible...).
Pour reprendre tes propres termes, lorsque le code est produit par un humain, je sais que je n'ai pas accès au niveau plus elevé qui démontre la correction (c'est l'aspect theologique), donc je dois comprendre ce que je vois, et pour ca il faut que ca soit lisible.
"kanze" <kanze@gabi-soft.fr> writes:
| Gabriel Dos Reis wrote:
| > "kanze" <kanze@gabi-soft.fr> writes:
|
| [...]
| > | La lisibilité est une condition nécessaire mais non suffisante
| > | de la correction.
|
| > En réalité, les deux sont orthogonales.
|
| Absolument pas. Un code qui n'est pas lisible n'est pas correct.
Ça c'est la théologie selon St James.
Pour la réalité, je suppose que tu as déjà entendu parler de code généré
automatiquement par des programmes. Pour la plus grande majorité, ils
sont illisibles. Leurs corrections sont souvent démontrées à un
niveau plus élévé où les algorithmes utilisés sont exprimés ainsi
que les chaînes d'inférence logiques utilisées.
J'acquiesce concernant du code genéré automatiquement par un autre
programme. Par contre, si le code a été généré par un humain, je serais
de l'avis de James (peut etre parce que je vois beaucoup de code
illisible...).
Pour reprendre tes propres termes, lorsque le code est produit par un
humain, je sais que je n'ai pas accès au niveau plus elevé qui démontre
la correction (c'est l'aspect theologique), donc je dois comprendre ce
que je vois, et pour ca il faut que ca soit lisible.
| Gabriel Dos Reis wrote: | > "kanze" writes: | | [...] | > | La lisibilité est une condition nécessaire mais non suffisante | > | de la correction. | | > En réalité, les deux sont orthogonales. | | Absolument pas. Un code qui n'est pas lisible n'est pas correct.
Ça c'est la théologie selon St James.
Pour la réalité, je suppose que tu as déjà entendu parler de code généré automatiquement par des programmes. Pour la plus grande majorité, ils sont illisibles. Leurs corrections sont souvent démontrées à un niveau plus élévé où les algorithmes utilisés sont exprimés ainsi que les chaînes d'inférence logiques utilisées.
J'acquiesce concernant du code genéré automatiquement par un autre programme. Par contre, si le code a été généré par un humain, je serais de l'avis de James (peut etre parce que je vois beaucoup de code illisible...).
Pour reprendre tes propres termes, lorsque le code est produit par un humain, je sais que je n'ai pas accès au niveau plus elevé qui démontre la correction (c'est l'aspect theologique), donc je dois comprendre ce que je vois, et pour ca il faut que ca soit lisible.
Gabriel Dos Reis
Michel Decima writes:
| > "kanze" writes: | > | Gabriel Dos Reis wrote: | > | > "kanze" writes: | > | | [...] | > | > | La lisibilité est une condition nécessaire mais non suffisante | > | > | de la correction. | > | | > En réalité, les deux sont orthogonales. | > | | Absolument pas. Un code qui n'est pas lisible n'est pas correct. | > Ça c'est la théologie selon St James. | > Pour la réalité, je suppose que tu as déjà entendu parler de code | > généré | > automatiquement par des programmes. Pour la plus grande majorité, ils | > sont illisibles. Leurs corrections sont souvent démontrées à un | > niveau plus élévé où les algorithmes utilisés sont exprimés ainsi | > que les chaînes d'inférence logiques utilisées. | | J'acquiesce concernant du code genéré automatiquement par un autre | programme. Par contre, si le code a été généré par un humain, je serais | de l'avis de James (peut etre parce que je vois beaucoup de code | illisible...). | | Pour reprendre tes propres termes, lorsque le code est produit par un | humain, je sais que je n'ai pas accès au niveau plus elevé qui démontre | la correction (c'est l'aspect theologique), donc je dois comprendre ce | que je vois, et pour ca il faut que ca soit lisible.
Je comprends tout à fait.
Cependant, le point est que la lisibilité n'implique pas la correction et vice-versa. On peut avoir un programme lisible est qui est incorrecte, tout simplement parce qu'il fait les « mauvaises » hypothèses ou qu'il se place à un niveau d'abstraction trop bas.
-- Gaby
Michel Decima <michel.decima@orange-ft.com> writes:
| > "kanze" <kanze@gabi-soft.fr> writes:
| > | Gabriel Dos Reis wrote:
| > | > "kanze" <kanze@gabi-soft.fr> writes:
| > | | [...]
| > | > | La lisibilité est une condition nécessaire mais non suffisante
| > | > | de la correction.
| > | | > En réalité, les deux sont orthogonales.
| > | | Absolument pas. Un code qui n'est pas lisible n'est pas correct.
| > Ça c'est la théologie selon St James.
| > Pour la réalité, je suppose que tu as déjà entendu parler de code
| > généré
| > automatiquement par des programmes. Pour la plus grande majorité, ils
| > sont illisibles. Leurs corrections sont souvent démontrées à un
| > niveau plus élévé où les algorithmes utilisés sont exprimés ainsi
| > que les chaînes d'inférence logiques utilisées.
|
| J'acquiesce concernant du code genéré automatiquement par un autre
| programme. Par contre, si le code a été généré par un humain, je serais
| de l'avis de James (peut etre parce que je vois beaucoup de code
| illisible...).
|
| Pour reprendre tes propres termes, lorsque le code est produit par un
| humain, je sais que je n'ai pas accès au niveau plus elevé qui démontre
| la correction (c'est l'aspect theologique), donc je dois comprendre ce
| que je vois, et pour ca il faut que ca soit lisible.
Je comprends tout à fait.
Cependant, le point est que la lisibilité n'implique pas la
correction et vice-versa. On peut avoir un programme lisible est qui
est incorrecte, tout simplement parce qu'il fait les « mauvaises »
hypothèses ou qu'il se place à un niveau d'abstraction trop bas.
| > "kanze" writes: | > | Gabriel Dos Reis wrote: | > | > "kanze" writes: | > | | [...] | > | > | La lisibilité est une condition nécessaire mais non suffisante | > | > | de la correction. | > | | > En réalité, les deux sont orthogonales. | > | | Absolument pas. Un code qui n'est pas lisible n'est pas correct. | > Ça c'est la théologie selon St James. | > Pour la réalité, je suppose que tu as déjà entendu parler de code | > généré | > automatiquement par des programmes. Pour la plus grande majorité, ils | > sont illisibles. Leurs corrections sont souvent démontrées à un | > niveau plus élévé où les algorithmes utilisés sont exprimés ainsi | > que les chaînes d'inférence logiques utilisées. | | J'acquiesce concernant du code genéré automatiquement par un autre | programme. Par contre, si le code a été généré par un humain, je serais | de l'avis de James (peut etre parce que je vois beaucoup de code | illisible...). | | Pour reprendre tes propres termes, lorsque le code est produit par un | humain, je sais que je n'ai pas accès au niveau plus elevé qui démontre | la correction (c'est l'aspect theologique), donc je dois comprendre ce | que je vois, et pour ca il faut que ca soit lisible.
Je comprends tout à fait.
Cependant, le point est que la lisibilité n'implique pas la correction et vice-versa. On peut avoir un programme lisible est qui est incorrecte, tout simplement parce qu'il fait les « mauvaises » hypothèses ou qu'il se place à un niveau d'abstraction trop bas.
-- Gaby
Michel Decima
| Pour reprendre tes propres termes, lorsque le code est produit par un | humain, je sais que je n'ai pas accès au niveau plus elevé qui démontre | la correction (c'est l'aspect theologique), donc je dois comprendre ce | que je vois, et pour ca il faut que ca soit lisible.
Je comprends tout à fait.
Cependant, le point est que la lisibilité n'implique pas la correction et vice-versa. On peut avoir un programme lisible est qui est incorrecte, tout simplement parce qu'il fait les « mauvaises » hypothèses ou qu'il se place à un niveau d'abstraction trop bas.
Ou qu'il a ete deliberement fait ainsi. J'ai lu recemment (je crois que c'est dans le dernier MISC, mais j ene l'ai pas sous la main, donc pas de reference) la description d'un concours qui vise a produire du code lisible, qui a l'air parfaitement inoffensif, mais qui contient une partie malicieuse (qui vise a declencher un exploit de securite). Une espece de IOCCC a l'envers.
| Pour reprendre tes propres termes, lorsque le code est produit par un
| humain, je sais que je n'ai pas accès au niveau plus elevé qui démontre
| la correction (c'est l'aspect theologique), donc je dois comprendre ce
| que je vois, et pour ca il faut que ca soit lisible.
Je comprends tout à fait.
Cependant, le point est que la lisibilité n'implique pas la
correction et vice-versa. On peut avoir un programme lisible est qui
est incorrecte, tout simplement parce qu'il fait les « mauvaises »
hypothèses ou qu'il se place à un niveau d'abstraction trop bas.
Ou qu'il a ete deliberement fait ainsi. J'ai lu recemment (je crois que
c'est dans le dernier MISC, mais j ene l'ai pas sous la main, donc pas
de reference) la description d'un concours qui vise a produire du code
lisible, qui a l'air parfaitement inoffensif, mais qui contient une
partie malicieuse (qui vise a declencher un exploit de securite).
Une espece de IOCCC a l'envers.
| Pour reprendre tes propres termes, lorsque le code est produit par un | humain, je sais que je n'ai pas accès au niveau plus elevé qui démontre | la correction (c'est l'aspect theologique), donc je dois comprendre ce | que je vois, et pour ca il faut que ca soit lisible.
Je comprends tout à fait.
Cependant, le point est que la lisibilité n'implique pas la correction et vice-versa. On peut avoir un programme lisible est qui est incorrecte, tout simplement parce qu'il fait les « mauvaises » hypothèses ou qu'il se place à un niveau d'abstraction trop bas.
Ou qu'il a ete deliberement fait ainsi. J'ai lu recemment (je crois que c'est dans le dernier MISC, mais j ene l'ai pas sous la main, donc pas de reference) la description d'un concours qui vise a produire du code lisible, qui a l'air parfaitement inoffensif, mais qui contient une partie malicieuse (qui vise a declencher un exploit de securite). Une espece de IOCCC a l'envers.
James Kanze
Gabriel Dos Reis wrote:
"kanze" writes:
| Gabriel Dos Reis wrote: | > "kanze" writes:
| > [...]
| > | La seule chose à ajouter, c'est que si tu écris une | > | bibliothèque, et tu ne sais pas trop où le client va traiter | > | l'erreur, il vaut mieux pécher du côté du code de retour. | > | Simplement parce que c'est beaucoup plus facile au client | > | d'écrire : | > | if ( f() != OK ) throw whatever ; | > | que d'écrire : | > | | > | try { | > | f() ; | > | } catch ( Whatever& error ) { | > | // ... | > | }
| > Je driais exactement l'opposé.
| Que c'est plus facile d'écrire cinq lignes, en ouvrant des blocs | de scope supplémentaire pour l'appel, que de n'en écrire | qu'une ?
Si la question est de compter le nombre de caractères écrits, il est beaucoup plus facile de ne pas en écrire du tout.
Si la question est d'écrire du code bibliothèque simple exprimant directement l'algorithme utilisé et qui marche, je maintiens mon affirmation.
Ce qui veut dire quoi ? Si je ne veux pas gerer l'erreur localement, j'emballe la fonction en question dans une petite fonction inline, du genre « if ... throw ». Rien de plus simple. S'il faut gerer l'erreur à ce niveau, la gestion doit en faire partie de l'algorithme, et en subir la même analyse. Et dans ce cas-là, ajouter des chemins importants irréguliers et partiellement invisible nuit à la claireté de l'analyse. Pour l'éviter, il faudrait emballer quasiment tout appel de fonction dans un bloc try/catch, qui est lourd à l'écriture.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Gabriel Dos Reis wrote:
"kanze" <kanze@gabi-soft.fr> writes:
| Gabriel Dos Reis wrote:
| > "kanze" <kanze@gabi-soft.fr> writes:
| > [...]
| > | La seule chose à ajouter, c'est que si tu écris une
| > | bibliothèque, et tu ne sais pas trop où le client va traiter
| > | l'erreur, il vaut mieux pécher du côté du code de retour.
| > | Simplement parce que c'est beaucoup plus facile au client
| > | d'écrire :
| > | if ( f() != OK ) throw whatever ;
| > | que d'écrire :
| > |
| > | try {
| > | f() ;
| > | } catch ( Whatever& error ) {
| > | // ...
| > | }
| > Je driais exactement l'opposé.
| Que c'est plus facile d'écrire cinq lignes, en ouvrant des blocs
| de scope supplémentaire pour l'appel, que de n'en écrire
| qu'une ?
Si la question est de compter le nombre de caractères écrits,
il est beaucoup plus facile de ne pas en écrire du tout.
Si la question est d'écrire du code bibliothèque simple
exprimant directement l'algorithme utilisé et qui marche, je
maintiens mon affirmation.
Ce qui veut dire quoi ? Si je ne veux pas gerer l'erreur
localement, j'emballe la fonction en question dans une petite
fonction inline, du genre « if ... throw ». Rien de plus
simple. S'il faut gerer l'erreur à ce niveau, la gestion doit en
faire partie de l'algorithme, et en subir la même analyse. Et
dans ce cas-là, ajouter des chemins importants irréguliers et
partiellement invisible nuit à la claireté de l'analyse. Pour
l'éviter, il faudrait emballer quasiment tout appel de fonction
dans un bloc try/catch, qui est lourd à l'écriture.
--
James Kanze kanze.james@neuf.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
| > | La seule chose à ajouter, c'est que si tu écris une | > | bibliothèque, et tu ne sais pas trop où le client va traiter | > | l'erreur, il vaut mieux pécher du côté du code de retour. | > | Simplement parce que c'est beaucoup plus facile au client | > | d'écrire : | > | if ( f() != OK ) throw whatever ; | > | que d'écrire : | > | | > | try { | > | f() ; | > | } catch ( Whatever& error ) { | > | // ... | > | }
| > Je driais exactement l'opposé.
| Que c'est plus facile d'écrire cinq lignes, en ouvrant des blocs | de scope supplémentaire pour l'appel, que de n'en écrire | qu'une ?
Si la question est de compter le nombre de caractères écrits, il est beaucoup plus facile de ne pas en écrire du tout.
Si la question est d'écrire du code bibliothèque simple exprimant directement l'algorithme utilisé et qui marche, je maintiens mon affirmation.
Ce qui veut dire quoi ? Si je ne veux pas gerer l'erreur localement, j'emballe la fonction en question dans une petite fonction inline, du genre « if ... throw ». Rien de plus simple. S'il faut gerer l'erreur à ce niveau, la gestion doit en faire partie de l'algorithme, et en subir la même analyse. Et dans ce cas-là, ajouter des chemins importants irréguliers et partiellement invisible nuit à la claireté de l'analyse. Pour l'éviter, il faudrait emballer quasiment tout appel de fonction dans un bloc try/catch, qui est lourd à l'écriture.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
James Kanze
Fabien LE LEZ wrote:
On 17 Aug 2006 03:47:08 -0700, "kanze" :
La seule chose à ajouter, c'est que si tu écris une bibliothèque, et tu ne sais pas trop où le client va traiter l'erreur,
J'ai quelques classes où le choix entre retour d'un code d'erreur et lancement d'exception se choisit en paramètre du constructeur.
Pour des bibliothèques générales, j'aime bien des callbacks. Même si je sais que je veux une exception, c'est l'utilisateur qui le choisit. Mais il faut se méfier aussi. Ce genre de solution signifie que toute bibliothèque qui utilise la classe soit en mesure de gerer toutes les solutions possibles. Ne pas savoir si l'erreur est rapportée par une exception ou par un code de retour n'est pas forcément un avantage non plus.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Fabien LE LEZ wrote:
On 17 Aug 2006 03:47:08 -0700, "kanze" <kanze@gabi-soft.fr>:
La seule chose à ajouter, c'est que si tu écris une
bibliothèque, et tu ne sais pas trop où le client va traiter
l'erreur,
J'ai quelques classes où le choix entre retour d'un code
d'erreur et lancement d'exception se choisit en paramètre du
constructeur.
Pour des bibliothèques générales, j'aime bien des callbacks.
Même si je sais que je veux une exception, c'est l'utilisateur
qui le choisit. Mais il faut se méfier aussi. Ce genre de
solution signifie que toute bibliothèque qui utilise la classe
soit en mesure de gerer toutes les solutions possibles. Ne pas
savoir si l'erreur est rapportée par une exception ou par un
code de retour n'est pas forcément un avantage non plus.
--
James Kanze kanze.james@neuf.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
La seule chose à ajouter, c'est que si tu écris une bibliothèque, et tu ne sais pas trop où le client va traiter l'erreur,
J'ai quelques classes où le choix entre retour d'un code d'erreur et lancement d'exception se choisit en paramètre du constructeur.
Pour des bibliothèques générales, j'aime bien des callbacks. Même si je sais que je veux une exception, c'est l'utilisateur qui le choisit. Mais il faut se méfier aussi. Ce genre de solution signifie que toute bibliothèque qui utilise la classe soit en mesure de gerer toutes les solutions possibles. Ne pas savoir si l'erreur est rapportée par une exception ou par un code de retour n'est pas forcément un avantage non plus.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Gabriel Dos Reis
"James Kanze" writes:
| Gabriel Dos Reis wrote: | > "kanze" writes: | | > | Gabriel Dos Reis wrote: | > | > "kanze" writes: | | > | > [...] | | > | > | La seule chose à ajouter, c'est que si tu écris une | > | > | bibliothèque, et tu ne sais pas trop où le client va traiter | > | > | l'erreur, il vaut mieux pécher du côté du code de retour. | > | > | Simplement parce que c'est beaucoup plus facile au client | > | > | d'écrire : | > | > | if ( f() != OK ) throw whatever ; | > | > | que d'écrire : | > | > | | > | > | try { | > | > | f() ; | > | > | } catch ( Whatever& error ) { | > | > | // ... | > | > | } | | > | > Je driais exactement l'opposé. | | > | Que c'est plus facile d'écrire cinq lignes, en ouvrant des blocs | > | de scope supplémentaire pour l'appel, que de n'en écrire | > | qu'une ? | | > Si la question est de compter le nombre de caractères écrits, | > il est beaucoup plus facile de ne pas en écrire du tout. | | > Si la question est d'écrire du code bibliothèque simple | > exprimant directement l'algorithme utilisé et qui marche, je | > maintiens mon affirmation. | | Ce qui veut dire quoi ?
Ce qui veut dire que si tu veux compter le nombre de ligne comme critère de facilité, alors c'est plus facile de ne pas en écrire.
Je peux comprendre que les exceptions apparaissent un chemin important et irrégulier à un esprit ignorant de l'outil C++. Dans ce cas, à part lui conseiller de changer de métier, je peux juste souhaiter qu'il apprenne rapidement à devenir familier avec elles.
-- Gaby
"James Kanze" <kanze.james@neuf.fr> writes:
| Gabriel Dos Reis wrote:
| > "kanze" <kanze@gabi-soft.fr> writes:
|
| > | Gabriel Dos Reis wrote:
| > | > "kanze" <kanze@gabi-soft.fr> writes:
|
| > | > [...]
|
| > | > | La seule chose à ajouter, c'est que si tu écris une
| > | > | bibliothèque, et tu ne sais pas trop où le client va traiter
| > | > | l'erreur, il vaut mieux pécher du côté du code de retour.
| > | > | Simplement parce que c'est beaucoup plus facile au client
| > | > | d'écrire :
| > | > | if ( f() != OK ) throw whatever ;
| > | > | que d'écrire :
| > | > |
| > | > | try {
| > | > | f() ;
| > | > | } catch ( Whatever& error ) {
| > | > | // ...
| > | > | }
|
| > | > Je driais exactement l'opposé.
|
| > | Que c'est plus facile d'écrire cinq lignes, en ouvrant des blocs
| > | de scope supplémentaire pour l'appel, que de n'en écrire
| > | qu'une ?
|
| > Si la question est de compter le nombre de caractères écrits,
| > il est beaucoup plus facile de ne pas en écrire du tout.
|
| > Si la question est d'écrire du code bibliothèque simple
| > exprimant directement l'algorithme utilisé et qui marche, je
| > maintiens mon affirmation.
|
| Ce qui veut dire quoi ?
Ce qui veut dire que si tu veux compter le nombre de ligne comme
critère de facilité, alors c'est plus facile de ne pas en écrire.
Je peux comprendre que les exceptions apparaissent un chemin important
et irrégulier à un esprit ignorant de l'outil C++. Dans ce cas, à part lui
conseiller de changer de métier, je peux juste souhaiter qu'il
apprenne rapidement à devenir familier avec elles.
| Gabriel Dos Reis wrote: | > "kanze" writes: | | > | Gabriel Dos Reis wrote: | > | > "kanze" writes: | | > | > [...] | | > | > | La seule chose à ajouter, c'est que si tu écris une | > | > | bibliothèque, et tu ne sais pas trop où le client va traiter | > | > | l'erreur, il vaut mieux pécher du côté du code de retour. | > | > | Simplement parce que c'est beaucoup plus facile au client | > | > | d'écrire : | > | > | if ( f() != OK ) throw whatever ; | > | > | que d'écrire : | > | > | | > | > | try { | > | > | f() ; | > | > | } catch ( Whatever& error ) { | > | > | // ... | > | > | } | | > | > Je driais exactement l'opposé. | | > | Que c'est plus facile d'écrire cinq lignes, en ouvrant des blocs | > | de scope supplémentaire pour l'appel, que de n'en écrire | > | qu'une ? | | > Si la question est de compter le nombre de caractères écrits, | > il est beaucoup plus facile de ne pas en écrire du tout. | | > Si la question est d'écrire du code bibliothèque simple | > exprimant directement l'algorithme utilisé et qui marche, je | > maintiens mon affirmation. | | Ce qui veut dire quoi ?
Ce qui veut dire que si tu veux compter le nombre de ligne comme critère de facilité, alors c'est plus facile de ne pas en écrire.
Je peux comprendre que les exceptions apparaissent un chemin important et irrégulier à un esprit ignorant de l'outil C++. Dans ce cas, à part lui conseiller de changer de métier, je peux juste souhaiter qu'il apprenne rapidement à devenir familier avec elles.
