A priori, on écrira Elements[l][c], et on se servir d'une version de la bibliothèque qui aborte le programme avec message d'erreur dans le cas où il y a une erreur de bornes.
Pas cool, ça. C'est très bien si tu arrives à simuler tous les cas possibles dans ta session de débogage.
Perso, je travaille uniquement sur des applications GUI. Et l'expérience prouve que les utilisateurs font parfois des trucs que personne n'avait prévu. Du coup, ils peuvent tomber sur des bugs non simulés en laboratoire. Et quand ça arrive, il faut que l'utilisateur puisse au moins sauvegarder son travail -- sinon, il est colère, à raison. Donc, abort() interdit.
On Sat, 16 Jul 2005 23:07:13 +0200, James Kanze <kanze@none>:
A priori, on écrira Elements[l][c], et on se servir d'une
version de la bibliothèque qui aborte le programme avec message
d'erreur dans le cas où il y a une erreur de bornes.
Pas cool, ça.
C'est très bien si tu arrives à simuler tous les cas possibles dans ta
session de débogage.
Perso, je travaille uniquement sur des applications GUI. Et
l'expérience prouve que les utilisateurs font parfois des trucs que
personne n'avait prévu. Du coup, ils peuvent tomber sur des bugs non
simulés en laboratoire. Et quand ça arrive, il faut que l'utilisateur
puisse au moins sauvegarder son travail -- sinon, il est colère, à
raison. Donc, abort() interdit.
A priori, on écrira Elements[l][c], et on se servir d'une version de la bibliothèque qui aborte le programme avec message d'erreur dans le cas où il y a une erreur de bornes.
Pas cool, ça. C'est très bien si tu arrives à simuler tous les cas possibles dans ta session de débogage.
Perso, je travaille uniquement sur des applications GUI. Et l'expérience prouve que les utilisateurs font parfois des trucs que personne n'avait prévu. Du coup, ils peuvent tomber sur des bugs non simulés en laboratoire. Et quand ça arrive, il faut que l'utilisateur puisse au moins sauvegarder son travail -- sinon, il est colère, à raison. Donc, abort() interdit.
kanze
Jean-Marc Desperrier wrote:
James Kanze wrote:
A priori, on écrira Elements[l][c], et on se servir d'une version de la bibliothèque qui aborte le programme avec message d'erreur dans le cas où il y a une erreur de bornes.
On n'utilise at() que si on veut une exception -- c-à-d qu'on s'attend à attrapper l'erreur plus haut et récupérer. Ce qui est très rare.
Les exceptions ralentissent le programme quand elles ne sont pas prises ?
Qui a parlé des performances ?
En tout cas je préfèrerais un exception de type accès mémoire à un abort, car la solution d'arrêter tout et de partir sur un abort dès qu'il y a un problème ne me semble pas universelle.
Le problème, c'est que tu es tombé sur un cas qui « ne peut pas se produire ». Il y a un invariant du programme qui est faux. Et une exception, ça fait executer beaucoup de code. Code qui suppose que les invariants tiennent. Du coup, la risque de faire plus de dégat encore est loin d'être negligeable.
Dans un certain nombre de programmes la robustesse est plus importante, et soit en travaillant sur la conception, soit en y arrivant facilement parceque la structure des opérations est simple, on souhaite plutôt placer un catch global rattrapant tous les types d'exception, annuler l'opération en cours, et continuer les opérations.
Tout dépend de la raison de l'exception. Si la raison est que tu as rencontré une condition impossible, non prévue par ton analyse, alors, la probabilité que tu puisses la rectifier est assez faible. Dans les systèmes critiques, dans de tels cas, la chose à faire est claire : abort, pour que le système de secours prend la main. Dans d'autres systèmes, il faut analyser. Mais il ne faut pas ignorer la risque que tu prend en faisant exécuter des destructeurs (et tu ne sais pas réelement lesquels) dans une contexte que tu ne connais pas.
-- 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
Jean-Marc Desperrier wrote:
James Kanze wrote:
A priori, on écrira Elements[l][c], et on se servir d'une
version de la bibliothèque qui aborte le programme avec
message d'erreur dans le cas où il y a une erreur de bornes.
On n'utilise at() que si on veut une exception -- c-à-d
qu'on s'attend à attrapper l'erreur plus haut et récupérer.
Ce qui est très rare.
Les exceptions ralentissent le programme quand elles ne sont
pas prises ?
Qui a parlé des performances ?
En tout cas je préfèrerais un exception de type accès mémoire
à un abort, car la solution d'arrêter tout et de partir sur un
abort dès qu'il y a un problème ne me semble pas universelle.
Le problème, c'est que tu es tombé sur un cas qui « ne peut pas
se produire ». Il y a un invariant du programme qui est faux. Et
une exception, ça fait executer beaucoup de code. Code qui
suppose que les invariants tiennent. Du coup, la risque de faire
plus de dégat encore est loin d'être negligeable.
Dans un certain nombre de programmes la robustesse est plus
importante, et soit en travaillant sur la conception, soit en
y arrivant facilement parceque la structure des opérations est
simple, on souhaite plutôt placer un catch global rattrapant
tous les types d'exception, annuler l'opération en cours, et
continuer les opérations.
Tout dépend de la raison de l'exception. Si la raison est que tu
as rencontré une condition impossible, non prévue par ton
analyse, alors, la probabilité que tu puisses la rectifier est
assez faible. Dans les systèmes critiques, dans de tels cas, la
chose à faire est claire : abort, pour que le système de secours
prend la main. Dans d'autres systèmes, il faut analyser. Mais il
ne faut pas ignorer la risque que tu prend en faisant exécuter
des destructeurs (et tu ne sais pas réelement lesquels) dans une
contexte que tu ne connais pas.
--
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
A priori, on écrira Elements[l][c], et on se servir d'une version de la bibliothèque qui aborte le programme avec message d'erreur dans le cas où il y a une erreur de bornes.
On n'utilise at() que si on veut une exception -- c-à-d qu'on s'attend à attrapper l'erreur plus haut et récupérer. Ce qui est très rare.
Les exceptions ralentissent le programme quand elles ne sont pas prises ?
Qui a parlé des performances ?
En tout cas je préfèrerais un exception de type accès mémoire à un abort, car la solution d'arrêter tout et de partir sur un abort dès qu'il y a un problème ne me semble pas universelle.
Le problème, c'est que tu es tombé sur un cas qui « ne peut pas se produire ». Il y a un invariant du programme qui est faux. Et une exception, ça fait executer beaucoup de code. Code qui suppose que les invariants tiennent. Du coup, la risque de faire plus de dégat encore est loin d'être negligeable.
Dans un certain nombre de programmes la robustesse est plus importante, et soit en travaillant sur la conception, soit en y arrivant facilement parceque la structure des opérations est simple, on souhaite plutôt placer un catch global rattrapant tous les types d'exception, annuler l'opération en cours, et continuer les opérations.
Tout dépend de la raison de l'exception. Si la raison est que tu as rencontré une condition impossible, non prévue par ton analyse, alors, la probabilité que tu puisses la rectifier est assez faible. Dans les systèmes critiques, dans de tels cas, la chose à faire est claire : abort, pour que le système de secours prend la main. Dans d'autres systèmes, il faut analyser. Mais il ne faut pas ignorer la risque que tu prend en faisant exécuter des destructeurs (et tu ne sais pas réelement lesquels) dans une contexte que tu ne connais pas.
-- 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:
On Sat, 16 Jul 2005 23:07:13 +0200, James Kanze :
A priori, on écrira Elements[l][c], et on se servir d'une version de la bibliothèque qui aborte le programme avec message d'erreur dans le cas où il y a une erreur de bornes.
Pas cool, ça.
Pas cool de livrer du code avec des erreurs. J'en conviens. Mais ça peut arriver.
C'est très bien si tu arrives à simuler tous les cas possibles dans ta session de débogage.
Je ne vois pas le rapport.
Perso, je travaille uniquement sur des applications GUI. Et l'expérience prouve que les utilisateurs font parfois des trucs que personne n'avait prévu.
Donc, tu affiches que tu n'as pas prévu le cas. Tu ne vas pas accéder à un tableau au delà des bornes parce que l'utilisateur à fait une bêtise, quand même.
Du coup, ils peuvent tomber sur des bugs non simulés en laboratoire.
Qui parle de simuler quoique ce soit en laboratoire. Tu te trouves dans une condition qui ne peut pas, logiquement, exister. Les invariants du code ne tiennent pas. Alors, tu vas te mettre à exécuter des tonnes de code qui dépend de ses invariants ?
Et quand ça arrive, il faut que l'utilisateur puisse au moins sauvegarder son travail -- sinon, il est colère, à raison. Donc, abort() interdit.
Et en quoi est-ce que l'abort() fait pire que si le OS même crash ? Il faut dire que les crash du système, sont bien plus fréquents que les échecs d'assertion, au moins avec des systèmes courants. Tu sauvegardes des étapes intermédiaires. Quand le programme rédémarre, il trouve les étapes sauvegarder, et effectue le nettoyage nécessaire. Que le crash soit du système ou de ton propre code.
-- 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:
On Sat, 16 Jul 2005 23:07:13 +0200, James Kanze <kanze@none>:
A priori, on écrira Elements[l][c], et on se servir d'une
version de la bibliothèque qui aborte le programme avec
message d'erreur dans le cas où il y a une erreur de bornes.
Pas cool, ça.
Pas cool de livrer du code avec des erreurs. J'en conviens. Mais
ça peut arriver.
C'est très bien si tu arrives à simuler tous les cas possibles
dans ta session de débogage.
Je ne vois pas le rapport.
Perso, je travaille uniquement sur des applications GUI. Et
l'expérience prouve que les utilisateurs font parfois des
trucs que personne n'avait prévu.
Donc, tu affiches que tu n'as pas prévu le cas. Tu ne vas pas
accéder à un tableau au delà des bornes parce que l'utilisateur
à fait une bêtise, quand même.
Du coup, ils peuvent tomber sur des bugs non simulés en
laboratoire.
Qui parle de simuler quoique ce soit en laboratoire. Tu te
trouves dans une condition qui ne peut pas, logiquement,
exister. Les invariants du code ne tiennent pas. Alors, tu vas
te mettre à exécuter des tonnes de code qui dépend de ses
invariants ?
Et quand ça arrive, il faut que l'utilisateur puisse au moins
sauvegarder son travail -- sinon, il est colère, à raison.
Donc, abort() interdit.
Et en quoi est-ce que l'abort() fait pire que si le OS même
crash ? Il faut dire que les crash du système, sont bien plus
fréquents que les échecs d'assertion, au moins avec des systèmes
courants. Tu sauvegardes des étapes intermédiaires. Quand le
programme rédémarre, il trouve les étapes sauvegarder, et
effectue le nettoyage nécessaire. Que le crash soit du système
ou de ton propre code.
--
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
A priori, on écrira Elements[l][c], et on se servir d'une version de la bibliothèque qui aborte le programme avec message d'erreur dans le cas où il y a une erreur de bornes.
Pas cool, ça.
Pas cool de livrer du code avec des erreurs. J'en conviens. Mais ça peut arriver.
C'est très bien si tu arrives à simuler tous les cas possibles dans ta session de débogage.
Je ne vois pas le rapport.
Perso, je travaille uniquement sur des applications GUI. Et l'expérience prouve que les utilisateurs font parfois des trucs que personne n'avait prévu.
Donc, tu affiches que tu n'as pas prévu le cas. Tu ne vas pas accéder à un tableau au delà des bornes parce que l'utilisateur à fait une bêtise, quand même.
Du coup, ils peuvent tomber sur des bugs non simulés en laboratoire.
Qui parle de simuler quoique ce soit en laboratoire. Tu te trouves dans une condition qui ne peut pas, logiquement, exister. Les invariants du code ne tiennent pas. Alors, tu vas te mettre à exécuter des tonnes de code qui dépend de ses invariants ?
Et quand ça arrive, il faut que l'utilisateur puisse au moins sauvegarder son travail -- sinon, il est colère, à raison. Donc, abort() interdit.
Et en quoi est-ce que l'abort() fait pire que si le OS même crash ? Il faut dire que les crash du système, sont bien plus fréquents que les échecs d'assertion, au moins avec des systèmes courants. Tu sauvegardes des étapes intermédiaires. Quand le programme rédémarre, il trouve les étapes sauvegarder, et effectue le nettoyage nécessaire. Que le crash soit du système ou de ton propre code.
-- 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
hannibal200480
wrote:
Fabien LE LEZ wrote:
On Sat, 16 Jul 2005 23:07:13 +0200, James Kanze :
A priori, on écrira Elements[l][c], et on se servir d'une version de la bibliothèque qui aborte le programme avec message d'erreur dans le cas où il y a une erreur de bornes.
Pas cool, ça.
Pas cool de livrer du code avec des erreurs. J'en conviens. Mais ça peut arriver.
C'est très bien si tu arrives à simuler tous les cas possibles dans ta session de débogage.
Je ne vois pas le rapport.
Perso, je travaille uniquement sur des applications GUI. Et l'expérience prouve que les utilisateurs font parfois des trucs que personne n'avait prévu.
Donc, tu affiches que tu n'as pas prévu le cas. Tu ne vas pas accéder à un tableau au delà des bornes parce que l'utilisateur à fait une bêtise, quand même.
Du coup, ils peuvent tomber sur des bugs non simulés en laboratoire.
Qui parle de simuler quoique ce soit en laboratoire. Tu te trouves dans une condition qui ne peut pas, logiquement, exister. Les invariants du code ne tiennent pas. Alors, tu vas te mettre à exécuter des tonnes de code qui dépend de ses invariants ?
Et quand ça arrive, il faut que l'utilisateur puisse au moins sauvegarder son travail -- sinon, il est colère, à raison. Donc, abort() interdit.
Et en quoi est-ce que l'abort() fait pire que si le OS même crash ? Il faut dire que les crash du système, sont bien plus fréquents que les échecs d'assertion, au moins avec des systèmes courants. Tu sauvegardes des étapes intermédiaires. Quand le programme rédémarre, il trouve les étapes sauvegarder, et effectue le nettoyage nécessaire. Que le crash soit du système ou de ton propre code.
-- 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
Merci pour vos idees.
hannibal
kanze@gabi-soft.fr wrote:
Fabien LE LEZ wrote:
On Sat, 16 Jul 2005 23:07:13 +0200, James Kanze <kanze@none>:
A priori, on écrira Elements[l][c], et on se servir d'une
version de la bibliothèque qui aborte le programme avec
message d'erreur dans le cas où il y a une erreur de bornes.
Pas cool, ça.
Pas cool de livrer du code avec des erreurs. J'en conviens. Mais
ça peut arriver.
C'est très bien si tu arrives à simuler tous les cas possibles
dans ta session de débogage.
Je ne vois pas le rapport.
Perso, je travaille uniquement sur des applications GUI. Et
l'expérience prouve que les utilisateurs font parfois des
trucs que personne n'avait prévu.
Donc, tu affiches que tu n'as pas prévu le cas. Tu ne vas pas
accéder à un tableau au delà des bornes parce que l'utilisateur
à fait une bêtise, quand même.
Du coup, ils peuvent tomber sur des bugs non simulés en
laboratoire.
Qui parle de simuler quoique ce soit en laboratoire. Tu te
trouves dans une condition qui ne peut pas, logiquement,
exister. Les invariants du code ne tiennent pas. Alors, tu vas
te mettre à exécuter des tonnes de code qui dépend de ses
invariants ?
Et quand ça arrive, il faut que l'utilisateur puisse au moins
sauvegarder son travail -- sinon, il est colère, à raison.
Donc, abort() interdit.
Et en quoi est-ce que l'abort() fait pire que si le OS même
crash ? Il faut dire que les crash du système, sont bien plus
fréquents que les échecs d'assertion, au moins avec des systèmes
courants. Tu sauvegardes des étapes intermédiaires. Quand le
programme rédémarre, il trouve les étapes sauvegarder, et
effectue le nettoyage nécessaire. Que le crash soit du système
ou de ton propre code.
--
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
A priori, on écrira Elements[l][c], et on se servir d'une version de la bibliothèque qui aborte le programme avec message d'erreur dans le cas où il y a une erreur de bornes.
Pas cool, ça.
Pas cool de livrer du code avec des erreurs. J'en conviens. Mais ça peut arriver.
C'est très bien si tu arrives à simuler tous les cas possibles dans ta session de débogage.
Je ne vois pas le rapport.
Perso, je travaille uniquement sur des applications GUI. Et l'expérience prouve que les utilisateurs font parfois des trucs que personne n'avait prévu.
Donc, tu affiches que tu n'as pas prévu le cas. Tu ne vas pas accéder à un tableau au delà des bornes parce que l'utilisateur à fait une bêtise, quand même.
Du coup, ils peuvent tomber sur des bugs non simulés en laboratoire.
Qui parle de simuler quoique ce soit en laboratoire. Tu te trouves dans une condition qui ne peut pas, logiquement, exister. Les invariants du code ne tiennent pas. Alors, tu vas te mettre à exécuter des tonnes de code qui dépend de ses invariants ?
Et quand ça arrive, il faut que l'utilisateur puisse au moins sauvegarder son travail -- sinon, il est colère, à raison. Donc, abort() interdit.
Et en quoi est-ce que l'abort() fait pire que si le OS même crash ? Il faut dire que les crash du système, sont bien plus fréquents que les échecs d'assertion, au moins avec des systèmes courants. Tu sauvegardes des étapes intermédiaires. Quand le programme rédémarre, il trouve les étapes sauvegarder, et effectue le nettoyage nécessaire. Que le crash soit du système ou de ton propre code.
-- 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
