cela peut être faux au runtime, mais ce n'est pas le
point et il faut faire avec l'existant);
Pour moi, c'est justement là tout le point.
A quoi ça servirait ? Tu aurais une fonction :
int f() throw (A, B);
Et l'utilisateur saurait en lisant ce prototype que la fonction peut
lancer soit A, soit B, soit n'importe quel autre type d'exception, mais
indirectement. Pas très utile comme spécification.
Proposes-tu que les fonctions avec une spécification d'exception n'aient
pas le droit d'appeler de fonction n'en ayant pas ?
Ca pourraît être une proposition acceptable, surtout utile AMA pour les
spécifications nothrow. Il faudrait pour ça patcher la bibliothèque
standard à 2/3 endroits (je pense par exemple à std::swap). Et dans ce
cas, il faudrait surtout que rien n'empêche une fonction sans
spécification d'appeler une fonction avec spécification. Un peu comme
const, en fait.
les nouvelles méthodes qui /choississent/ de déclarer leurs exceptions
imposerait en effet à leur utilisateur et supplanteur la même
'corvée', mais est-ce bien grave ?
Il n'a jamais marché. Et dans le code que je fais, où souvent les
exceptions ne sont gérées qu'au niveau le plus haut pour arrêter le
programme avec un code d'erreur, j'aurais aisément 3 à 4 fois plus de
lignes pour spécifier mes exceptions que pour le corps de mes fonctions.
L'intérêt des exceptions est de séparer traitement de l'erreur de sa
localisation. Si on doit écrire des choses pour chaque fonction, je ne
vois plus l'intérêt.
Mes deux propositions étaient exclusives.
Si tu pense que la première est acceptable ...
cela peut être faux au runtime, mais ce n'est pas le
point et il faut faire avec l'existant);
Pour moi, c'est justement là tout le point.
A quoi ça servirait ? Tu aurais une fonction :
int f() throw (A, B);
Et l'utilisateur saurait en lisant ce prototype que la fonction peut
lancer soit A, soit B, soit n'importe quel autre type d'exception, mais
indirectement. Pas très utile comme spécification.
Proposes-tu que les fonctions avec une spécification d'exception n'aient
pas le droit d'appeler de fonction n'en ayant pas ?
Ca pourraît être une proposition acceptable, surtout utile AMA pour les
spécifications nothrow. Il faudrait pour ça patcher la bibliothèque
standard à 2/3 endroits (je pense par exemple à std::swap). Et dans ce
cas, il faudrait surtout que rien n'empêche une fonction sans
spécification d'appeler une fonction avec spécification. Un peu comme
const, en fait.
les nouvelles méthodes qui /choississent/ de déclarer leurs exceptions
imposerait en effet à leur utilisateur et supplanteur la même
'corvée', mais est-ce bien grave ?
Il n'a jamais marché. Et dans le code que je fais, où souvent les
exceptions ne sont gérées qu'au niveau le plus haut pour arrêter le
programme avec un code d'erreur, j'aurais aisément 3 à 4 fois plus de
lignes pour spécifier mes exceptions que pour le corps de mes fonctions.
L'intérêt des exceptions est de séparer traitement de l'erreur de sa
localisation. Si on doit écrire des choses pour chaque fonction, je ne
vois plus l'intérêt.
Mes deux propositions étaient exclusives.
Si tu pense que la première est acceptable ...
cela peut être faux au runtime, mais ce n'est pas le
point et il faut faire avec l'existant);
Pour moi, c'est justement là tout le point.
A quoi ça servirait ? Tu aurais une fonction :
int f() throw (A, B);
Et l'utilisateur saurait en lisant ce prototype que la fonction peut
lancer soit A, soit B, soit n'importe quel autre type d'exception, mais
indirectement. Pas très utile comme spécification.
Proposes-tu que les fonctions avec une spécification d'exception n'aient
pas le droit d'appeler de fonction n'en ayant pas ?
Ca pourraît être une proposition acceptable, surtout utile AMA pour les
spécifications nothrow. Il faudrait pour ça patcher la bibliothèque
standard à 2/3 endroits (je pense par exemple à std::swap). Et dans ce
cas, il faudrait surtout que rien n'empêche une fonction sans
spécification d'appeler une fonction avec spécification. Un peu comme
const, en fait.
les nouvelles méthodes qui /choississent/ de déclarer leurs exceptions
imposerait en effet à leur utilisateur et supplanteur la même
'corvée', mais est-ce bien grave ?
Il n'a jamais marché. Et dans le code que je fais, où souvent les
exceptions ne sont gérées qu'au niveau le plus haut pour arrêter le
programme avec un code d'erreur, j'aurais aisément 3 à 4 fois plus de
lignes pour spécifier mes exceptions que pour le corps de mes fonctions.
L'intérêt des exceptions est de séparer traitement de l'erreur de sa
localisation. Si on doit écrire des choses pour chaque fonction, je ne
vois plus l'intérêt.
Mes deux propositions étaient exclusives.
Si tu pense que la première est acceptable ...
Loïc Joly wrote on 23/07/2006 05:00:
cela peut être faux au runtime, mais ce n'est pas le point et il faut
faire avec l'existant);
Pour moi, c'est justement là tout le point.
pourquoi ? et qu'a-t-il d'original qui ne soit pas déjà traité depuis
que les exceptions existent ?
A quoi ça servirait ? Tu aurais une fonction :
int f() throw (A, B);
Et l'utilisateur saurait en lisant ce prototype que la fonction peut
lancer soit A, soit B, soit n'importe quel autre type d'exception,
mais indirectement. Pas très utile comme spécification.
"demerde toi sans aucune info" n'est pas plus "utile comme spécification"
ici il pourra au moins faire:
try {
f();
} catch (A a){
// traiter la raison de 'a'
} catch (B b){
// traiter la raison de 'b'
} catch (...){
// prevenir l'utilisateur qu'il est planté et que l'auteur du code ne
sait pas pourquoi
}
ne pas avoir la spécification des exceptions nous ramène sur le dernier
cas où on ne sait jamais qui a planté ni pourquoi; tellement utile que
l'on ne voudrait rien à changer ??
Proposes-tu que les fonctions avec une spécification d'exception
n'aient pas le droit d'appeler de fonction n'en ayant pas ?
j'ai indiqué le contraire (et tu as commenté la violation au runtime).
toutefois la syntaxe actuelle gère très bien le cas:
ayant void foo() throw (A,B);
void g() throw (){ foo(); } est invalide
void h(){ foo(); } est valide
void j() throw (A,B){ foo(); } est valide
void k() throw (){
try {
foo();
} catch (A){
} catch (B){
}
}
est valide
Il n'a jamais marché. Et dans le code que je fais, où souvent les
exceptions ne sont gérées qu'au niveau le plus haut pour arrêter le
programme avec un code d'erreur, j'aurais aisément 3 à 4 fois plus de
lignes pour spécifier mes exceptions que pour le corps de mes fonctions.
ce code /que tu fais/ fait règle ? pour ma part que préfère le
traitement local (au niveau le plus près).
je rappelle que la syntaxe actuelle sans aucune spécification permet de
transmettre toute exception - tu opposes donc un argument de contrainte
inacceptable là où justement tu n'as et continuera à n'avoir aucune
contrainte.
L'intérêt des exceptions est de séparer traitement de l'erreur de sa
localisation. Si on doit écrire des choses pour chaque fonction, je ne
vois plus l'intérêt.
si tes fonctions sont manichéennes (process normal ou core dump) soit;
là encore je pense que la vraie vie est un peu plus subtile.
Loïc Joly wrote on 23/07/2006 05:00:
cela peut être faux au runtime, mais ce n'est pas le point et il faut
faire avec l'existant);
Pour moi, c'est justement là tout le point.
pourquoi ? et qu'a-t-il d'original qui ne soit pas déjà traité depuis
que les exceptions existent ?
A quoi ça servirait ? Tu aurais une fonction :
int f() throw (A, B);
Et l'utilisateur saurait en lisant ce prototype que la fonction peut
lancer soit A, soit B, soit n'importe quel autre type d'exception,
mais indirectement. Pas très utile comme spécification.
"demerde toi sans aucune info" n'est pas plus "utile comme spécification"
ici il pourra au moins faire:
try {
f();
} catch (A a){
// traiter la raison de 'a'
} catch (B b){
// traiter la raison de 'b'
} catch (...){
// prevenir l'utilisateur qu'il est planté et que l'auteur du code ne
sait pas pourquoi
}
ne pas avoir la spécification des exceptions nous ramène sur le dernier
cas où on ne sait jamais qui a planté ni pourquoi; tellement utile que
l'on ne voudrait rien à changer ??
Proposes-tu que les fonctions avec une spécification d'exception
n'aient pas le droit d'appeler de fonction n'en ayant pas ?
j'ai indiqué le contraire (et tu as commenté la violation au runtime).
toutefois la syntaxe actuelle gère très bien le cas:
ayant void foo() throw (A,B);
void g() throw (){ foo(); } est invalide
void h(){ foo(); } est valide
void j() throw (A,B){ foo(); } est valide
void k() throw (){
try {
foo();
} catch (A){
} catch (B){
}
}
est valide
Il n'a jamais marché. Et dans le code que je fais, où souvent les
exceptions ne sont gérées qu'au niveau le plus haut pour arrêter le
programme avec un code d'erreur, j'aurais aisément 3 à 4 fois plus de
lignes pour spécifier mes exceptions que pour le corps de mes fonctions.
ce code /que tu fais/ fait règle ? pour ma part que préfère le
traitement local (au niveau le plus près).
je rappelle que la syntaxe actuelle sans aucune spécification permet de
transmettre toute exception - tu opposes donc un argument de contrainte
inacceptable là où justement tu n'as et continuera à n'avoir aucune
contrainte.
L'intérêt des exceptions est de séparer traitement de l'erreur de sa
localisation. Si on doit écrire des choses pour chaque fonction, je ne
vois plus l'intérêt.
si tes fonctions sont manichéennes (process normal ou core dump) soit;
là encore je pense que la vraie vie est un peu plus subtile.
Loïc Joly wrote on 23/07/2006 05:00:
cela peut être faux au runtime, mais ce n'est pas le point et il faut
faire avec l'existant);
Pour moi, c'est justement là tout le point.
pourquoi ? et qu'a-t-il d'original qui ne soit pas déjà traité depuis
que les exceptions existent ?
A quoi ça servirait ? Tu aurais une fonction :
int f() throw (A, B);
Et l'utilisateur saurait en lisant ce prototype que la fonction peut
lancer soit A, soit B, soit n'importe quel autre type d'exception,
mais indirectement. Pas très utile comme spécification.
"demerde toi sans aucune info" n'est pas plus "utile comme spécification"
ici il pourra au moins faire:
try {
f();
} catch (A a){
// traiter la raison de 'a'
} catch (B b){
// traiter la raison de 'b'
} catch (...){
// prevenir l'utilisateur qu'il est planté et que l'auteur du code ne
sait pas pourquoi
}
ne pas avoir la spécification des exceptions nous ramène sur le dernier
cas où on ne sait jamais qui a planté ni pourquoi; tellement utile que
l'on ne voudrait rien à changer ??
Proposes-tu que les fonctions avec une spécification d'exception
n'aient pas le droit d'appeler de fonction n'en ayant pas ?
j'ai indiqué le contraire (et tu as commenté la violation au runtime).
toutefois la syntaxe actuelle gère très bien le cas:
ayant void foo() throw (A,B);
void g() throw (){ foo(); } est invalide
void h(){ foo(); } est valide
void j() throw (A,B){ foo(); } est valide
void k() throw (){
try {
foo();
} catch (A){
} catch (B){
}
}
est valide
Il n'a jamais marché. Et dans le code que je fais, où souvent les
exceptions ne sont gérées qu'au niveau le plus haut pour arrêter le
programme avec un code d'erreur, j'aurais aisément 3 à 4 fois plus de
lignes pour spécifier mes exceptions que pour le corps de mes fonctions.
ce code /que tu fais/ fait règle ? pour ma part que préfère le
traitement local (au niveau le plus près).
je rappelle que la syntaxe actuelle sans aucune spécification permet de
transmettre toute exception - tu opposes donc un argument de contrainte
inacceptable là où justement tu n'as et continuera à n'avoir aucune
contrainte.
L'intérêt des exceptions est de séparer traitement de l'erreur de sa
localisation. Si on doit écrire des choses pour chaque fonction, je ne
vois plus l'intérêt.
si tes fonctions sont manichéennes (process normal ou core dump) soit;
là encore je pense que la vraie vie est un peu plus subtile.
James Kanze wrote on 23/07/2006 12:57:
Il oblige en fait à catcher ou à lister toutes les exceptions
qui aurait dû être des codes de retour:-). Et qui le sont en
C++, en général.
tu aurais pu indiquer: les erreurs que /tu/ prefères retourner
via un code de retour.
je te rapelles qu'une méthode retournant une instance
nouvellement créé ne peux le faire via un param variant (ptr&)
et donc n'a d'autre choix que de lever un exception si
l'opération ne peut être réalisée.
au delà des conséquences de cette absence de pointeurs, il
reste (heureusement) les choix personnels, prétendre ce qui
/devrait être/ présuppose que tout n'a qu'une seule écriture
possible, je ne crois pas cela.
on peux noter également qu'en C++ ces codes retours ne règlent
pas tout loin s'en faut, si j'écris par exemple un streamer
d'extraction, je peux vouloir coder:
Bytes& operator >> (Bytes&, bool&)
throw (ArrayIndexOutOfBoundsException);
Bytes& operator >> (Bytes&, byte&)
throw (ArrayIndexOutOfBoundsException);
etc ...
il est évident que de tels cas (les exemples ne manquerait
pas) ne s'accorde pas avec la stratégie du code de retour.
le choix de la STL et de _CATCH_IO_END qui positionne un
indicateur interne pour continuer son process est une
possibilité (à mi chemin) que je n'affectionne pas vraiment
(reste aussi que ma question n'était pas liée à la STL).
returnType methodeName {
try {
// whatever
}
catch (Throwable err){
}
}
Et entre la fin du bloc de catch et le retour, il y a toujours
une possibilité d'un « VirtualMachineError ». (Un bon exemple
d'une chose qui ne doit jamais être une exception.)
si tu écris ton byte-code à la main peut être, sinon ?...
(par contre la machine peut être éteinte au milieu de la
méthode, soit)
Mais ce n'était pas mon propo. Je disais que tu ne pouvais
jamais écrire cette garantie. La déclaration de ta fonction
methodeName, ci-dessus, ne comporte aucune garantie en ce qui
concerne ni les Error ni les RuntimeException.
Error et RuntimeException (et toutes leurs classes filles)
étendent Throwable et seront catchées ici (mais ce n'est pas
le propos).
On est arrivé à un point en C++ où on peut ajouter de
nouveaux features, mais on ne peut pas toucher à l'existant.
soit, pourquoi dans ce cas avoir défini 'throw(...)' dans la
déclaration d'une fonction/méthode ?
James Kanze wrote on 23/07/2006 12:57:
Il oblige en fait à catcher ou à lister toutes les exceptions
qui aurait dû être des codes de retour:-). Et qui le sont en
C++, en général.
tu aurais pu indiquer: les erreurs que /tu/ prefères retourner
via un code de retour.
je te rapelles qu'une méthode retournant une instance
nouvellement créé ne peux le faire via un param variant (ptr&)
et donc n'a d'autre choix que de lever un exception si
l'opération ne peut être réalisée.
au delà des conséquences de cette absence de pointeurs, il
reste (heureusement) les choix personnels, prétendre ce qui
/devrait être/ présuppose que tout n'a qu'une seule écriture
possible, je ne crois pas cela.
on peux noter également qu'en C++ ces codes retours ne règlent
pas tout loin s'en faut, si j'écris par exemple un streamer
d'extraction, je peux vouloir coder:
Bytes& operator >> (Bytes&, bool&)
throw (ArrayIndexOutOfBoundsException);
Bytes& operator >> (Bytes&, byte&)
throw (ArrayIndexOutOfBoundsException);
etc ...
il est évident que de tels cas (les exemples ne manquerait
pas) ne s'accorde pas avec la stratégie du code de retour.
le choix de la STL et de _CATCH_IO_END qui positionne un
indicateur interne pour continuer son process est une
possibilité (à mi chemin) que je n'affectionne pas vraiment
(reste aussi que ma question n'était pas liée à la STL).
returnType methodeName {
try {
// whatever
}
catch (Throwable err){
}
}
Et entre la fin du bloc de catch et le retour, il y a toujours
une possibilité d'un « VirtualMachineError ». (Un bon exemple
d'une chose qui ne doit jamais être une exception.)
si tu écris ton byte-code à la main peut être, sinon ?...
(par contre la machine peut être éteinte au milieu de la
méthode, soit)
Mais ce n'était pas mon propo. Je disais que tu ne pouvais
jamais écrire cette garantie. La déclaration de ta fonction
methodeName, ci-dessus, ne comporte aucune garantie en ce qui
concerne ni les Error ni les RuntimeException.
Error et RuntimeException (et toutes leurs classes filles)
étendent Throwable et seront catchées ici (mais ce n'est pas
le propos).
On est arrivé à un point en C++ où on peut ajouter de
nouveaux features, mais on ne peut pas toucher à l'existant.
soit, pourquoi dans ce cas avoir défini 'throw(...)' dans la
déclaration d'une fonction/méthode ?
James Kanze wrote on 23/07/2006 12:57:
Il oblige en fait à catcher ou à lister toutes les exceptions
qui aurait dû être des codes de retour:-). Et qui le sont en
C++, en général.
tu aurais pu indiquer: les erreurs que /tu/ prefères retourner
via un code de retour.
je te rapelles qu'une méthode retournant une instance
nouvellement créé ne peux le faire via un param variant (ptr&)
et donc n'a d'autre choix que de lever un exception si
l'opération ne peut être réalisée.
au delà des conséquences de cette absence de pointeurs, il
reste (heureusement) les choix personnels, prétendre ce qui
/devrait être/ présuppose que tout n'a qu'une seule écriture
possible, je ne crois pas cela.
on peux noter également qu'en C++ ces codes retours ne règlent
pas tout loin s'en faut, si j'écris par exemple un streamer
d'extraction, je peux vouloir coder:
Bytes& operator >> (Bytes&, bool&)
throw (ArrayIndexOutOfBoundsException);
Bytes& operator >> (Bytes&, byte&)
throw (ArrayIndexOutOfBoundsException);
etc ...
il est évident que de tels cas (les exemples ne manquerait
pas) ne s'accorde pas avec la stratégie du code de retour.
le choix de la STL et de _CATCH_IO_END qui positionne un
indicateur interne pour continuer son process est une
possibilité (à mi chemin) que je n'affectionne pas vraiment
(reste aussi que ma question n'était pas liée à la STL).
returnType methodeName {
try {
// whatever
}
catch (Throwable err){
}
}
Et entre la fin du bloc de catch et le retour, il y a toujours
une possibilité d'un « VirtualMachineError ». (Un bon exemple
d'une chose qui ne doit jamais être une exception.)
si tu écris ton byte-code à la main peut être, sinon ?...
(par contre la machine peut être éteinte au milieu de la
méthode, soit)
Mais ce n'était pas mon propo. Je disais que tu ne pouvais
jamais écrire cette garantie. La déclaration de ta fonction
methodeName, ci-dessus, ne comporte aucune garantie en ce qui
concerne ni les Error ni les RuntimeException.
Error et RuntimeException (et toutes leurs classes filles)
étendent Throwable et seront catchées ici (mais ce n'est pas
le propos).
On est arrivé à un point en C++ où on peut ajouter de
nouveaux features, mais on ne peut pas toucher à l'existant.
soit, pourquoi dans ce cas avoir défini 'throw(...)' dans la
déclaration d'une fonction/méthode ?
Quand une indication n'apporte aucune sûreté supplémentaire que ce que
des commentaires apporteraient, je ne vois pas pourquoi la faire entrer
dans le langage.
L'intérêt de passer du commentaire dans du langage (comme const, par
exemple) existe uniquement si le langage peut s'assurer que cet
ex-commentaire est vrai.
Avec ta proposition, je ne vois vraiment pas en
quoi le langage pourrait vérifier quoi que ce soit.
comportement actuel de Visual C++ qui ignore ces spécifications
fait exactement ce que tu souhaites...
toutefois la syntaxe actuelle gère très bien le cas:
ayant void foo() throw (A,B);
void g() throw (){ foo(); } est invalide
void h(){ foo(); } est valide
void j() throw (A,B){ foo(); } est valide
void k() throw (){
try {
foo();
} catch (A){
} catch (B){
}
}
est valide
Je ne sais pas ce que tu entends par valide, mais tous ces bouts de code
sont légaux en C++ actuellement.
Si j'ai bien compris ce que tu souhaites, écrire :
void f() throw ()
{
throw 1;
}
Serait invalide et détecté à la compilation
mais écrire
void f(à throw ()
{
g();
}
void g()
{
throw 1;
}
Serait valide, à la compilation comme au run-time ?
Je trouve ça assez moche.
J'aime bien aussi le traitement local, dans la plupart des cas. Et pour
le traitement local, je n'ai jamais ressenti le besoin des exceptions.
Le but des exceptions est quand le traitement est non local. C'est pour
ça qu'elles ont été introduites dans le langage.
L'intérêt des exceptions est de séparer traitement de l'erreur de sa
localisation. Si on doit écrire des choses pour chaque fonction, je
ne vois plus l'intérêt.
si tes fonctions sont manichéennes (process normal ou core dump) soit;
là encore je pense que la vraie vie est un peu plus subtile.
Je ne comprends pas trop ce que tu dis.
Quand une indication n'apporte aucune sûreté supplémentaire que ce que
des commentaires apporteraient, je ne vois pas pourquoi la faire entrer
dans le langage.
L'intérêt de passer du commentaire dans du langage (comme const, par
exemple) existe uniquement si le langage peut s'assurer que cet
ex-commentaire est vrai.
Avec ta proposition, je ne vois vraiment pas en
quoi le langage pourrait vérifier quoi que ce soit.
comportement actuel de Visual C++ qui ignore ces spécifications
fait exactement ce que tu souhaites...
toutefois la syntaxe actuelle gère très bien le cas:
ayant void foo() throw (A,B);
void g() throw (){ foo(); } est invalide
void h(){ foo(); } est valide
void j() throw (A,B){ foo(); } est valide
void k() throw (){
try {
foo();
} catch (A){
} catch (B){
}
}
est valide
Je ne sais pas ce que tu entends par valide, mais tous ces bouts de code
sont légaux en C++ actuellement.
Si j'ai bien compris ce que tu souhaites, écrire :
void f() throw ()
{
throw 1;
}
Serait invalide et détecté à la compilation
mais écrire
void f(à throw ()
{
g();
}
void g()
{
throw 1;
}
Serait valide, à la compilation comme au run-time ?
Je trouve ça assez moche.
J'aime bien aussi le traitement local, dans la plupart des cas. Et pour
le traitement local, je n'ai jamais ressenti le besoin des exceptions.
Le but des exceptions est quand le traitement est non local. C'est pour
ça qu'elles ont été introduites dans le langage.
L'intérêt des exceptions est de séparer traitement de l'erreur de sa
localisation. Si on doit écrire des choses pour chaque fonction, je
ne vois plus l'intérêt.
si tes fonctions sont manichéennes (process normal ou core dump) soit;
là encore je pense que la vraie vie est un peu plus subtile.
Je ne comprends pas trop ce que tu dis.
Quand une indication n'apporte aucune sûreté supplémentaire que ce que
des commentaires apporteraient, je ne vois pas pourquoi la faire entrer
dans le langage.
L'intérêt de passer du commentaire dans du langage (comme const, par
exemple) existe uniquement si le langage peut s'assurer que cet
ex-commentaire est vrai.
Avec ta proposition, je ne vois vraiment pas en
quoi le langage pourrait vérifier quoi que ce soit.
comportement actuel de Visual C++ qui ignore ces spécifications
fait exactement ce que tu souhaites...
toutefois la syntaxe actuelle gère très bien le cas:
ayant void foo() throw (A,B);
void g() throw (){ foo(); } est invalide
void h(){ foo(); } est valide
void j() throw (A,B){ foo(); } est valide
void k() throw (){
try {
foo();
} catch (A){
} catch (B){
}
}
est valide
Je ne sais pas ce que tu entends par valide, mais tous ces bouts de code
sont légaux en C++ actuellement.
Si j'ai bien compris ce que tu souhaites, écrire :
void f() throw ()
{
throw 1;
}
Serait invalide et détecté à la compilation
mais écrire
void f(à throw ()
{
g();
}
void g()
{
throw 1;
}
Serait valide, à la compilation comme au run-time ?
Je trouve ça assez moche.
J'aime bien aussi le traitement local, dans la plupart des cas. Et pour
le traitement local, je n'ai jamais ressenti le besoin des exceptions.
Le but des exceptions est quand le traitement est non local. C'est pour
ça qu'elles ont été introduites dans le langage.
L'intérêt des exceptions est de séparer traitement de l'erreur de sa
localisation. Si on doit écrire des choses pour chaque fonction, je
ne vois plus l'intérêt.
si tes fonctions sont manichéennes (process normal ou core dump) soit;
là encore je pense que la vraie vie est un peu plus subtile.
Je ne comprends pas trop ce que tu dis.
Je sais que parfois, on s'en sert pour contourner d'autres
défauts du langage.
Mais même. Fallible n'est pas vraiment une nouveauté.
Les flux sont un cas particulier. Où en C++ le choix a été
laissé à l'utilisateur. N'empêche que dans la plupart des cas,
c'est un des rares cas où un état dans l'objet est la politique
qui convient le mieux.
le choix de la STL et de _CATCH_IO_END qui positionne un
indicateur interne pour continuer son process est une
possibilité (à mi chemin) que je n'affectionne pas vraiment
(reste aussi que ma question n'était pas liée à la STL).
Là, tu me perds complétement. D'abord, qu'est-ce que la STL a à
voir ici ? Et c'est quoi, _CATCH_IO_END ?
returnType methodeName {
try {
// whatever
}
catch (Throwable err){
}
}
Error et RuntimeException (et toutes leurs classes filles)
étendent Throwable et seront catchées ici (mais ce n'est pas
le propos).
Où est-ce que ta déclaration dit ça ?
Je sais que parfois, on s'en sert pour contourner d'autres
défauts du langage.
Mais même. Fallible n'est pas vraiment une nouveauté.
Les flux sont un cas particulier. Où en C++ le choix a été
laissé à l'utilisateur. N'empêche que dans la plupart des cas,
c'est un des rares cas où un état dans l'objet est la politique
qui convient le mieux.
le choix de la STL et de _CATCH_IO_END qui positionne un
indicateur interne pour continuer son process est une
possibilité (à mi chemin) que je n'affectionne pas vraiment
(reste aussi que ma question n'était pas liée à la STL).
Là, tu me perds complétement. D'abord, qu'est-ce que la STL a à
voir ici ? Et c'est quoi, _CATCH_IO_END ?
returnType methodeName {
try {
// whatever
}
catch (Throwable err){
}
}
Error et RuntimeException (et toutes leurs classes filles)
étendent Throwable et seront catchées ici (mais ce n'est pas
le propos).
Où est-ce que ta déclaration dit ça ?
Je sais que parfois, on s'en sert pour contourner d'autres
défauts du langage.
Mais même. Fallible n'est pas vraiment une nouveauté.
Les flux sont un cas particulier. Où en C++ le choix a été
laissé à l'utilisateur. N'empêche que dans la plupart des cas,
c'est un des rares cas où un état dans l'objet est la politique
qui convient le mieux.
le choix de la STL et de _CATCH_IO_END qui positionne un
indicateur interne pour continuer son process est une
possibilité (à mi chemin) que je n'affectionne pas vraiment
(reste aussi que ma question n'était pas liée à la STL).
Là, tu me perds complétement. D'abord, qu'est-ce que la STL a à
voir ici ? Et c'est quoi, _CATCH_IO_END ?
returnType methodeName {
try {
// whatever
}
catch (Throwable err){
}
}
Error et RuntimeException (et toutes leurs classes filles)
étendent Throwable et seront catchées ici (mais ce n'est pas
le propos).
Où est-ce que ta déclaration dit ça ?
void f(à throw ()
{
g();
}
void g()
{
throw 1;
}
Serait valide, à la compilation comme au run-time ?
Je trouve ça assez moche.
void f(à throw ()
{
g();
}
void g()
{
throw 1;
}
Serait valide, à la compilation comme au run-time ?
Je trouve ça assez moche.
void f(à throw ()
{
g();
}
void g()
{
throw 1;
}
Serait valide, à la compilation comme au run-time ?
Je trouve ça assez moche.
James Kanze wrote on 23/07/2006 23:30:Je sais que parfois, on s'en sert pour contourner d'autres
défauts du langage.
ce n'est pas un défaut mais un choix - tes arguments ne
gagnent rien à s'accompagner de dénigrement.
Mais même. Fallible n'est pas vraiment une nouveauté.
ce package de P2P me parait un peu anecdotique non ?
ce principe me parait lourd et est peu satisfaisant (pour le
contexte décrit; il est peut être pertinent dans leur contexte
où des instances modifiables peuvent être modifiées par
différent intervenant (thread client, scheduler, manager
global, ?...); dans une telle distribution positionner un état
interne est peut être plus simple que de lever une exception
ne sachant pas si l'appelant est exception savvy).
Les flux sont un cas particulier. Où en C++ le choix a été
laissé à l'utilisateur. N'empêche que dans la plupart des
cas, c'est un des rares cas où un état dans l'objet est la
politique qui convient le mieux.
je ne partage pas cet avis en tant que règle universelle ("la
plupart des cas"); j'ai des cas ou c'est (un état) très
satisfaisant et d'autres ou l'objet est suffisamment fugace et
opaque (de type inconnu) pour préférer sortir en exception.
le choix de la STL et de _CATCH_IO_END qui positionne un
indicateur interne pour continuer son process est une
possibilité (à mi chemin) que je n'affectionne pas
vraiment (reste aussi que ma question n'était pas liée à
la STL).
Là, tu me perds complétement. D'abord, qu'est-ce que la STL
a à voir ici ? Et c'est quoi, _CATCH_IO_END ?
la STL a à voir qu'elle utilise justement "un état dans
l'objet" pour enregistrer les erreurs survenant durant une
lecture depuis un stream.
_CATCH_IO_END est le nom de la macro positionnant le flag
d'erreur dans l'implémentation de P.J. Plauger.
returnType methodeName {
try {
// whatever
}
catch (Throwable err){
}
}
Error et RuntimeException (et toutes leurs classes
filles) étendent Throwable et seront catchées ici (mais
ce n'est pas le propos).
Où est-ce que ta déclaration dit ça ?
un handler d'exception Java catche les erreurs de son type
argument et toutes les classes filles de ce type. le
comportement de java est ici le même que celui de C++ (enfin
là où applicable évidemment, dans la pratique un catch pouvant
recevoir des types primitifs, des références clonées, des
pointeurs, ..., le seul type générique que je connaisse est en
fait '...').
James Kanze wrote on 23/07/2006 23:30:
Je sais que parfois, on s'en sert pour contourner d'autres
défauts du langage.
ce n'est pas un défaut mais un choix - tes arguments ne
gagnent rien à s'accompagner de dénigrement.
Mais même. Fallible n'est pas vraiment une nouveauté.
ce package de P2P me parait un peu anecdotique non ?
ce principe me parait lourd et est peu satisfaisant (pour le
contexte décrit; il est peut être pertinent dans leur contexte
où des instances modifiables peuvent être modifiées par
différent intervenant (thread client, scheduler, manager
global, ?...); dans une telle distribution positionner un état
interne est peut être plus simple que de lever une exception
ne sachant pas si l'appelant est exception savvy).
Les flux sont un cas particulier. Où en C++ le choix a été
laissé à l'utilisateur. N'empêche que dans la plupart des
cas, c'est un des rares cas où un état dans l'objet est la
politique qui convient le mieux.
je ne partage pas cet avis en tant que règle universelle ("la
plupart des cas"); j'ai des cas ou c'est (un état) très
satisfaisant et d'autres ou l'objet est suffisamment fugace et
opaque (de type inconnu) pour préférer sortir en exception.
le choix de la STL et de _CATCH_IO_END qui positionne un
indicateur interne pour continuer son process est une
possibilité (à mi chemin) que je n'affectionne pas
vraiment (reste aussi que ma question n'était pas liée à
la STL).
Là, tu me perds complétement. D'abord, qu'est-ce que la STL
a à voir ici ? Et c'est quoi, _CATCH_IO_END ?
la STL a à voir qu'elle utilise justement "un état dans
l'objet" pour enregistrer les erreurs survenant durant une
lecture depuis un stream.
_CATCH_IO_END est le nom de la macro positionnant le flag
d'erreur dans l'implémentation de P.J. Plauger.
returnType methodeName {
try {
// whatever
}
catch (Throwable err){
}
}
Error et RuntimeException (et toutes leurs classes
filles) étendent Throwable et seront catchées ici (mais
ce n'est pas le propos).
Où est-ce que ta déclaration dit ça ?
un handler d'exception Java catche les erreurs de son type
argument et toutes les classes filles de ce type. le
comportement de java est ici le même que celui de C++ (enfin
là où applicable évidemment, dans la pratique un catch pouvant
recevoir des types primitifs, des références clonées, des
pointeurs, ..., le seul type générique que je connaisse est en
fait '...').
James Kanze wrote on 23/07/2006 23:30:Je sais que parfois, on s'en sert pour contourner d'autres
défauts du langage.
ce n'est pas un défaut mais un choix - tes arguments ne
gagnent rien à s'accompagner de dénigrement.
Mais même. Fallible n'est pas vraiment une nouveauté.
ce package de P2P me parait un peu anecdotique non ?
ce principe me parait lourd et est peu satisfaisant (pour le
contexte décrit; il est peut être pertinent dans leur contexte
où des instances modifiables peuvent être modifiées par
différent intervenant (thread client, scheduler, manager
global, ?...); dans une telle distribution positionner un état
interne est peut être plus simple que de lever une exception
ne sachant pas si l'appelant est exception savvy).
Les flux sont un cas particulier. Où en C++ le choix a été
laissé à l'utilisateur. N'empêche que dans la plupart des
cas, c'est un des rares cas où un état dans l'objet est la
politique qui convient le mieux.
je ne partage pas cet avis en tant que règle universelle ("la
plupart des cas"); j'ai des cas ou c'est (un état) très
satisfaisant et d'autres ou l'objet est suffisamment fugace et
opaque (de type inconnu) pour préférer sortir en exception.
le choix de la STL et de _CATCH_IO_END qui positionne un
indicateur interne pour continuer son process est une
possibilité (à mi chemin) que je n'affectionne pas
vraiment (reste aussi que ma question n'était pas liée à
la STL).
Là, tu me perds complétement. D'abord, qu'est-ce que la STL
a à voir ici ? Et c'est quoi, _CATCH_IO_END ?
la STL a à voir qu'elle utilise justement "un état dans
l'objet" pour enregistrer les erreurs survenant durant une
lecture depuis un stream.
_CATCH_IO_END est le nom de la macro positionnant le flag
d'erreur dans l'implémentation de P.J. Plauger.
returnType methodeName {
try {
// whatever
}
catch (Throwable err){
}
}
Error et RuntimeException (et toutes leurs classes
filles) étendent Throwable et seront catchées ici (mais
ce n'est pas le propos).
Où est-ce que ta déclaration dit ça ?
un handler d'exception Java catche les erreurs de son type
argument et toutes les classes filles de ce type. le
comportement de java est ici le même que celui de C++ (enfin
là où applicable évidemment, dans la pratique un catch pouvant
recevoir des types primitifs, des références clonées, des
pointeurs, ..., le seul type générique que je connaisse est en
fait '...').
Un défaut peu bien être le résultat d'un choix.
Le fait reste que le Java n'a pas de paramètres en sortie
aller savoir pourquoi,
et que des paramètres en sortie sont bien utile parfois.
Je ne sais pas trop de quoi tu parles ici, mais ce n'est pas
l'idiome de Fallible connu des programmeurs C++.
Je sais que parfois, on s'en sert pour contourner d'autres
défauts du langage. Mais même. Fallible n'est pas vraiment
une nouveauté.
Tu as des cas où un flux est un objet fugace et opaque ?
J'ai l'impression que tu confonds toujours. La STL n'a rien à
voir avec les flux, [...]
Je ne crois pas que tu aies compris la distinction entre la
déclaration (le contrat) et l'implémentation. Je ne vais pas
lire la source d'une fonction pour savoir ce qu'elle fait. Je
lis sa declaration, c-à-d son contrat.
Maintenant, il est clair qu'on ne peut pas mettre tout dans une
declaration ; il faut de la documentation aussi. Et je n'ai
rien contre ceux en C++ qui dit que les spécifications des
exceptions ont une valeur limitée, et qu'à part throw(), on ne
s'en sert pas. Mais dire que le Java fait mieux, c'est faux ;
on ne peut même pas declarer au niveau du langage qu'une
fonction ne sort jamais par une exception.
... le C++ n'offre qu'une erreur à l'exécution,
et le Java n'offre rien.
Un défaut peu bien être le résultat d'un choix.
Le fait reste que le Java n'a pas de paramètres en sortie
aller savoir pourquoi,
et que des paramètres en sortie sont bien utile parfois.
Je ne sais pas trop de quoi tu parles ici, mais ce n'est pas
l'idiome de Fallible connu des programmeurs C++.
Je sais que parfois, on s'en sert pour contourner d'autres
défauts du langage. Mais même. Fallible n'est pas vraiment
une nouveauté.
Tu as des cas où un flux est un objet fugace et opaque ?
J'ai l'impression que tu confonds toujours. La STL n'a rien à
voir avec les flux, [...]
Je ne crois pas que tu aies compris la distinction entre la
déclaration (le contrat) et l'implémentation. Je ne vais pas
lire la source d'une fonction pour savoir ce qu'elle fait. Je
lis sa declaration, c-à-d son contrat.
Maintenant, il est clair qu'on ne peut pas mettre tout dans une
declaration ; il faut de la documentation aussi. Et je n'ai
rien contre ceux en C++ qui dit que les spécifications des
exceptions ont une valeur limitée, et qu'à part throw(), on ne
s'en sert pas. Mais dire que le Java fait mieux, c'est faux ;
on ne peut même pas declarer au niveau du langage qu'une
fonction ne sort jamais par une exception.
... le C++ n'offre qu'une erreur à l'exécution,
et le Java n'offre rien.
Un défaut peu bien être le résultat d'un choix.
Le fait reste que le Java n'a pas de paramètres en sortie
aller savoir pourquoi,
et que des paramètres en sortie sont bien utile parfois.
Je ne sais pas trop de quoi tu parles ici, mais ce n'est pas
l'idiome de Fallible connu des programmeurs C++.
Je sais que parfois, on s'en sert pour contourner d'autres
défauts du langage. Mais même. Fallible n'est pas vraiment
une nouveauté.
Tu as des cas où un flux est un objet fugace et opaque ?
J'ai l'impression que tu confonds toujours. La STL n'a rien à
voir avec les flux, [...]
Je ne crois pas que tu aies compris la distinction entre la
déclaration (le contrat) et l'implémentation. Je ne vais pas
lire la source d'une fonction pour savoir ce qu'elle fait. Je
lis sa declaration, c-à-d son contrat.
Maintenant, il est clair qu'on ne peut pas mettre tout dans une
declaration ; il faut de la documentation aussi. Et je n'ai
rien contre ceux en C++ qui dit que les spécifications des
exceptions ont une valeur limitée, et qu'à part throw(), on ne
s'en sert pas. Mais dire que le Java fait mieux, c'est faux ;
on ne peut même pas declarer au niveau du langage qu'une
fonction ne sort jamais par une exception.
... le C++ n'offre qu'une erreur à l'exécution,
et le Java n'offre rien.
kanze wrote on 24/07/2006 09:35:Le fait reste que le Java n'a pas de paramètres en sortie
?! c'est quoi un "paramètre en sortie" ??
si tu parles de sortie d'une méthode au sens propre, si, elle
peut retourner un résultat non void.
si tu parles de paramètres par référence, toute instance est
passé par référence et peut donc être modifiée.
si tu voulais dire paramètre de type primitif variant, en
effet cela n'existe pas ...
aller savoir pourquoi,
... parce qu'il semblerait que les pointeurs n'existent pas
...
et que des paramètres en sortie sont bien utile parfois.
... mais rien n'empèche, par exemple, de transmettre une
instance de Integer pour assumer le role d'un int& du C++.
Je ne sais pas trop de quoi tu parles ici, mais ce n'est pas
l'idiome de Fallible connu des programmeurs C++.
hmm, hmm, je te cite:Je sais que parfois, on s'en sert pour contourner d'autres
défauts du langage. Mais même. Fallible n'est pas vraiment
une nouveauté.
tu parlais de Java, je t'ai répondu sur Java; bravo de railler
ma réponse en changeant de sujet.
Tu as des cas où un flux est un objet fugace et opaque ?
couramment pourquoi ?
J'ai l'impression que tu confonds toujours. La STL n'a rien
à voir avec les flux, [...]
tu sais moi du moment que ça s'appelle std::machin ...
Je ne crois pas que tu aies compris la distinction entre la
déclaration (le contrat) et l'implémentation. Je ne vais pas
lire la source d'une fonction pour savoir ce qu'elle fait.
Je lis sa declaration, c-à-d son contrat.
tu te moques de moi là ou quoi ???????
la garantie est évidemment dans la déclaration (et justement
plus en Java qui force à lister ou à catcher les exceptions
qu'en C++ qui se fout bien des exceptions listées).
au cas où cela t'aura echappé, une déclaration Java (on parle
de cela) comme "returnType methodeName()" est *la* garantie
qu'elle ne throw rien; contrairement au "throw()" de C++,
c'est ici l'absence d'indication qui est la garantie.
on peut reboucler sur "y-a pas d'exception quand la machine
crashe",
je te renvoie vers les specs Java pour la différence entre une
erreur applicative *qui doit être catchée ou listée* et une
erreur machine / VM / autre qui est réputée 'unrecoverable' et
qui n'est donc pas du ressort d'une méthode applicative.
Maintenant, il est clair qu'on ne peut pas mettre tout dans
une declaration ; il faut de la documentation aussi. Et je
n'ai rien contre ceux en C++ qui dit que les spécifications
des exceptions ont une valeur limitée, et qu'à part throw(),
on ne s'en sert pas. Mais dire que le Java fait mieux, c'est
faux ; on ne peut même pas declarer au niveau du langage
qu'une fonction ne sort jamais par une exception.
faux voir ci-dessus.
on trouve parfois ce vieil adage chez les dinosaures Cistes -
développeur système s'il en est - pour penser qu'ils
contrôlent tout; si la comparaison vaut ici pour prétendre
qu'il est impossible de "déclarer qu'une fonction ne sort
jamais par une exception" quand il s'agit d'exception de l'OS,
du runtime ou toute plante externe à l'appli., alors le point
est archaïque et non pertinent.
... le C++ n'offre qu'une erreur à l'exécution,
et le Java n'offre rien.
continue le C++ ! tu as clairement manqué des chapitres sur
Java.
kanze wrote on 24/07/2006 09:35:
Le fait reste que le Java n'a pas de paramètres en sortie
?! c'est quoi un "paramètre en sortie" ??
si tu parles de sortie d'une méthode au sens propre, si, elle
peut retourner un résultat non void.
si tu parles de paramètres par référence, toute instance est
passé par référence et peut donc être modifiée.
si tu voulais dire paramètre de type primitif variant, en
effet cela n'existe pas ...
aller savoir pourquoi,
... parce qu'il semblerait que les pointeurs n'existent pas
...
et que des paramètres en sortie sont bien utile parfois.
... mais rien n'empèche, par exemple, de transmettre une
instance de Integer pour assumer le role d'un int& du C++.
Je ne sais pas trop de quoi tu parles ici, mais ce n'est pas
l'idiome de Fallible connu des programmeurs C++.
hmm, hmm, je te cite:
Je sais que parfois, on s'en sert pour contourner d'autres
défauts du langage. Mais même. Fallible n'est pas vraiment
une nouveauté.
tu parlais de Java, je t'ai répondu sur Java; bravo de railler
ma réponse en changeant de sujet.
Tu as des cas où un flux est un objet fugace et opaque ?
couramment pourquoi ?
J'ai l'impression que tu confonds toujours. La STL n'a rien
à voir avec les flux, [...]
tu sais moi du moment que ça s'appelle std::machin ...
Je ne crois pas que tu aies compris la distinction entre la
déclaration (le contrat) et l'implémentation. Je ne vais pas
lire la source d'une fonction pour savoir ce qu'elle fait.
Je lis sa declaration, c-à-d son contrat.
tu te moques de moi là ou quoi ???????
la garantie est évidemment dans la déclaration (et justement
plus en Java qui force à lister ou à catcher les exceptions
qu'en C++ qui se fout bien des exceptions listées).
au cas où cela t'aura echappé, une déclaration Java (on parle
de cela) comme "returnType methodeName()" est *la* garantie
qu'elle ne throw rien; contrairement au "throw()" de C++,
c'est ici l'absence d'indication qui est la garantie.
on peut reboucler sur "y-a pas d'exception quand la machine
crashe",
je te renvoie vers les specs Java pour la différence entre une
erreur applicative *qui doit être catchée ou listée* et une
erreur machine / VM / autre qui est réputée 'unrecoverable' et
qui n'est donc pas du ressort d'une méthode applicative.
Maintenant, il est clair qu'on ne peut pas mettre tout dans
une declaration ; il faut de la documentation aussi. Et je
n'ai rien contre ceux en C++ qui dit que les spécifications
des exceptions ont une valeur limitée, et qu'à part throw(),
on ne s'en sert pas. Mais dire que le Java fait mieux, c'est
faux ; on ne peut même pas declarer au niveau du langage
qu'une fonction ne sort jamais par une exception.
faux voir ci-dessus.
on trouve parfois ce vieil adage chez les dinosaures Cistes -
développeur système s'il en est - pour penser qu'ils
contrôlent tout; si la comparaison vaut ici pour prétendre
qu'il est impossible de "déclarer qu'une fonction ne sort
jamais par une exception" quand il s'agit d'exception de l'OS,
du runtime ou toute plante externe à l'appli., alors le point
est archaïque et non pertinent.
... le C++ n'offre qu'une erreur à l'exécution,
et le Java n'offre rien.
continue le C++ ! tu as clairement manqué des chapitres sur
Java.
kanze wrote on 24/07/2006 09:35:Le fait reste que le Java n'a pas de paramètres en sortie
?! c'est quoi un "paramètre en sortie" ??
si tu parles de sortie d'une méthode au sens propre, si, elle
peut retourner un résultat non void.
si tu parles de paramètres par référence, toute instance est
passé par référence et peut donc être modifiée.
si tu voulais dire paramètre de type primitif variant, en
effet cela n'existe pas ...
aller savoir pourquoi,
... parce qu'il semblerait que les pointeurs n'existent pas
...
et que des paramètres en sortie sont bien utile parfois.
... mais rien n'empèche, par exemple, de transmettre une
instance de Integer pour assumer le role d'un int& du C++.
Je ne sais pas trop de quoi tu parles ici, mais ce n'est pas
l'idiome de Fallible connu des programmeurs C++.
hmm, hmm, je te cite:Je sais que parfois, on s'en sert pour contourner d'autres
défauts du langage. Mais même. Fallible n'est pas vraiment
une nouveauté.
tu parlais de Java, je t'ai répondu sur Java; bravo de railler
ma réponse en changeant de sujet.
Tu as des cas où un flux est un objet fugace et opaque ?
couramment pourquoi ?
J'ai l'impression que tu confonds toujours. La STL n'a rien
à voir avec les flux, [...]
tu sais moi du moment que ça s'appelle std::machin ...
Je ne crois pas que tu aies compris la distinction entre la
déclaration (le contrat) et l'implémentation. Je ne vais pas
lire la source d'une fonction pour savoir ce qu'elle fait.
Je lis sa declaration, c-à-d son contrat.
tu te moques de moi là ou quoi ???????
la garantie est évidemment dans la déclaration (et justement
plus en Java qui force à lister ou à catcher les exceptions
qu'en C++ qui se fout bien des exceptions listées).
au cas où cela t'aura echappé, une déclaration Java (on parle
de cela) comme "returnType methodeName()" est *la* garantie
qu'elle ne throw rien; contrairement au "throw()" de C++,
c'est ici l'absence d'indication qui est la garantie.
on peut reboucler sur "y-a pas d'exception quand la machine
crashe",
je te renvoie vers les specs Java pour la différence entre une
erreur applicative *qui doit être catchée ou listée* et une
erreur machine / VM / autre qui est réputée 'unrecoverable' et
qui n'est donc pas du ressort d'une méthode applicative.
Maintenant, il est clair qu'on ne peut pas mettre tout dans
une declaration ; il faut de la documentation aussi. Et je
n'ai rien contre ceux en C++ qui dit que les spécifications
des exceptions ont une valeur limitée, et qu'à part throw(),
on ne s'en sert pas. Mais dire que le Java fait mieux, c'est
faux ; on ne peut même pas declarer au niveau du langage
qu'une fonction ne sort jamais par une exception.
faux voir ci-dessus.
on trouve parfois ce vieil adage chez les dinosaures Cistes -
développeur système s'il en est - pour penser qu'ils
contrôlent tout; si la comparaison vaut ici pour prétendre
qu'il est impossible de "déclarer qu'une fonction ne sort
jamais par une exception" quand il s'agit d'exception de l'OS,
du runtime ou toute plante externe à l'appli., alors le point
est archaïque et non pertinent.
... le C++ n'offre qu'une erreur à l'exécution,
et le Java n'offre rien.
continue le C++ ! tu as clairement manqué des chapitres sur
Java.
Je parlais de ce qu'on appelle les « out parameters » en
anglais.
Java ne supporte ni out, ni inout.
(Le C++, en fait, ne supporte pas réelement
out non plus. Mais on arrive aux mêmes
fins avec des inout la plupart du temps.)
C'est un concepte assez connu, il me semble.
À titre d'exemple, essayer d'écrire l'équivalant en Java de
std::swap.
Je n'arrive pas à comprendre ce que tu ne comprends pas. Tu sais
très bien que le Java ne t'oblige à lister que certaines
exceptions, non toutes. C'est là le problème, parce que la
garantie la plus intéressante, c'est bien qu'il n'y aura pas
d'exception. Du tout. Qu'elle hérite de RuntimeException ou de
Error, ou non. C'est dans la pratique peut-être la seule
garantie un peu près utile.
Idéalement, on l'aurait, et elle
serait vérifiée par le compilateur. En C++, on l'a, mais avec
vérification lors de l'exécution -- c'est loin d'être idéal,
mais c'est mieux que rien.
C'est à croire que tu connais ni le Java, ni le C++, parce que
tu l'a exactement à l'envers. La déclaration ci-dessus en Java
garantie seulement que la fonction ne peut pas lever une parmi
un petit sous-ensemble des exceptions. Et j'ai déjà (souvent
d'ailleurs) vu des fonctions Java avec une déclaration pareille
sortir par une exception.
Quand tu spécifies throw() sur une fonction en C++, en revanche,
tu es 100% sûr que la fonction ne sortira jamais par une
exception.
La seule différence entre les deux, c'est qu'il faut en citer
les unes dans la déclaration de la fonction, mais pas les
autres. C'est vraiement la seule différence, selon le langage.
Et si tu régardes les cas réels, dans la API de Java, tu
constateras que les seules qu'il faut lister, ce sont celles
qu'il faut typiquement traiter à un niveau tout près. C-à-d
celles où on se servira d'un code de rétour d'une fonction en
C++, parce que c'est quand même moins lourd.
L'exemple typique où une exception est la solution préférée,
c'est std::bad_alloc (en C++) ou java.lang.OutOfMemoryError (en
Java). C'est un cas type où l'erreur ne pourrait pas être
traitée localement.
Il y en a beaucoup de ce genre qui dérivent
de RuntimeException ; ce sont des erreurs que, si on veut les
traiter, il faut les traiter à un niveau assez élevé,
Il vaut peut-être mieux régarder les spécifications du langage,
non ? Pour Java (§8.4.4) :
Clairement, toutes les exceptions ne sont pas égales, et on peut
sortir d'une fonction par une exception (« unchecked »), même
s'il n'apparaît pas dans le throws clause.
En C++ (§15.4/8,9) :
Pas de distinction entre deux catégories d'exception. Et s'il y
a une exception-specification, c'est véritablement une
garantie : quoi qui arrive, on ne sort pas avec une exception
qui n'est pas citée, et si elle est vide, on ne sort pas de la
fonction avec une exception.
Je te conseille de lire la spécification de Java avant de
parler.
Je parlais de ce qu'on appelle les « out parameters » en
anglais.
Java ne supporte ni out, ni inout.
(Le C++, en fait, ne supporte pas réelement
out non plus. Mais on arrive aux mêmes
fins avec des inout la plupart du temps.)
C'est un concepte assez connu, il me semble.
À titre d'exemple, essayer d'écrire l'équivalant en Java de
std::swap.
Je n'arrive pas à comprendre ce que tu ne comprends pas. Tu sais
très bien que le Java ne t'oblige à lister que certaines
exceptions, non toutes. C'est là le problème, parce que la
garantie la plus intéressante, c'est bien qu'il n'y aura pas
d'exception. Du tout. Qu'elle hérite de RuntimeException ou de
Error, ou non. C'est dans la pratique peut-être la seule
garantie un peu près utile.
Idéalement, on l'aurait, et elle
serait vérifiée par le compilateur. En C++, on l'a, mais avec
vérification lors de l'exécution -- c'est loin d'être idéal,
mais c'est mieux que rien.
C'est à croire que tu connais ni le Java, ni le C++, parce que
tu l'a exactement à l'envers. La déclaration ci-dessus en Java
garantie seulement que la fonction ne peut pas lever une parmi
un petit sous-ensemble des exceptions. Et j'ai déjà (souvent
d'ailleurs) vu des fonctions Java avec une déclaration pareille
sortir par une exception.
Quand tu spécifies throw() sur une fonction en C++, en revanche,
tu es 100% sûr que la fonction ne sortira jamais par une
exception.
La seule différence entre les deux, c'est qu'il faut en citer
les unes dans la déclaration de la fonction, mais pas les
autres. C'est vraiement la seule différence, selon le langage.
Et si tu régardes les cas réels, dans la API de Java, tu
constateras que les seules qu'il faut lister, ce sont celles
qu'il faut typiquement traiter à un niveau tout près. C-à-d
celles où on se servira d'un code de rétour d'une fonction en
C++, parce que c'est quand même moins lourd.
L'exemple typique où une exception est la solution préférée,
c'est std::bad_alloc (en C++) ou java.lang.OutOfMemoryError (en
Java). C'est un cas type où l'erreur ne pourrait pas être
traitée localement.
Il y en a beaucoup de ce genre qui dérivent
de RuntimeException ; ce sont des erreurs que, si on veut les
traiter, il faut les traiter à un niveau assez élevé,
Il vaut peut-être mieux régarder les spécifications du langage,
non ? Pour Java (§8.4.4) :
Clairement, toutes les exceptions ne sont pas égales, et on peut
sortir d'une fonction par une exception (« unchecked »), même
s'il n'apparaît pas dans le throws clause.
En C++ (§15.4/8,9) :
Pas de distinction entre deux catégories d'exception. Et s'il y
a une exception-specification, c'est véritablement une
garantie : quoi qui arrive, on ne sort pas avec une exception
qui n'est pas citée, et si elle est vide, on ne sort pas de la
fonction avec une exception.
Je te conseille de lire la spécification de Java avant de
parler.
Je parlais de ce qu'on appelle les « out parameters » en
anglais.
Java ne supporte ni out, ni inout.
(Le C++, en fait, ne supporte pas réelement
out non plus. Mais on arrive aux mêmes
fins avec des inout la plupart du temps.)
C'est un concepte assez connu, il me semble.
À titre d'exemple, essayer d'écrire l'équivalant en Java de
std::swap.
Je n'arrive pas à comprendre ce que tu ne comprends pas. Tu sais
très bien que le Java ne t'oblige à lister que certaines
exceptions, non toutes. C'est là le problème, parce que la
garantie la plus intéressante, c'est bien qu'il n'y aura pas
d'exception. Du tout. Qu'elle hérite de RuntimeException ou de
Error, ou non. C'est dans la pratique peut-être la seule
garantie un peu près utile.
Idéalement, on l'aurait, et elle
serait vérifiée par le compilateur. En C++, on l'a, mais avec
vérification lors de l'exécution -- c'est loin d'être idéal,
mais c'est mieux que rien.
C'est à croire que tu connais ni le Java, ni le C++, parce que
tu l'a exactement à l'envers. La déclaration ci-dessus en Java
garantie seulement que la fonction ne peut pas lever une parmi
un petit sous-ensemble des exceptions. Et j'ai déjà (souvent
d'ailleurs) vu des fonctions Java avec une déclaration pareille
sortir par une exception.
Quand tu spécifies throw() sur une fonction en C++, en revanche,
tu es 100% sûr que la fonction ne sortira jamais par une
exception.
La seule différence entre les deux, c'est qu'il faut en citer
les unes dans la déclaration de la fonction, mais pas les
autres. C'est vraiement la seule différence, selon le langage.
Et si tu régardes les cas réels, dans la API de Java, tu
constateras que les seules qu'il faut lister, ce sont celles
qu'il faut typiquement traiter à un niveau tout près. C-à-d
celles où on se servira d'un code de rétour d'une fonction en
C++, parce que c'est quand même moins lourd.
L'exemple typique où une exception est la solution préférée,
c'est std::bad_alloc (en C++) ou java.lang.OutOfMemoryError (en
Java). C'est un cas type où l'erreur ne pourrait pas être
traitée localement.
Il y en a beaucoup de ce genre qui dérivent
de RuntimeException ; ce sont des erreurs que, si on veut les
traiter, il faut les traiter à un niveau assez élevé,
Il vaut peut-être mieux régarder les spécifications du langage,
non ? Pour Java (§8.4.4) :
Clairement, toutes les exceptions ne sont pas égales, et on peut
sortir d'une fonction par une exception (« unchecked »), même
s'il n'apparaît pas dans le throws clause.
En C++ (§15.4/8,9) :
Pas de distinction entre deux catégories d'exception. Et s'il y
a une exception-specification, c'est véritablement une
garantie : quoi qui arrive, on ne sort pas avec une exception
qui n'est pas citée, et si elle est vide, on ne sort pas de la
fonction avec une exception.
Je te conseille de lire la spécification de Java avant de
parler.
