language

Pourquoi est-ce que le "principe" des exceptions non descendantes
de java.lang.RuntimeException est mauvais ?

Le principe ne l'est pas en essence. Ce qui est mauvais, c'est
d'avoir appelé ça exception, et de l'avoir présenté comme le
mécanisme normal des exceptions. C'est en réalité une sorte de type
union pour le retour (_local_) d'erreur, avec un mécanisme de
transmission (déclaré au niveau de la fonction) automatique.

Je vois, mais je trouve que ça à des avantages pratiques (séparer les
types de retour "normaux" des types dévolus à l'expression d'erreur).

Sauf qu'une exception n'est pas nécessairement une "erreur". Dans
une optique événementielle, "tout" est exception, par exemple :
clic, double-clic, événement clavier...

Dans la terminologie de java je ne crois pas que "tout" soit
exception. Je ne vois pas le rapport avec ce qui précède en fait.

Stéphane Zuckerman , dans le message

D'un autre côté, Java est prouvé pour les types (y'a du lambda calcul et
tout le toutim pour le faire), ce qui fait qu'il n'y aura jamais d'erreur
de type avec un programme "stuck" à cause de ça. Et c'est franchement un
mieux par rapport à C.
À condition de parler de java 1.5, et le programmer de manière incompatible

avec les versions précédentes,

Je trouve complètement ahurissant le niveau d'incompatibilité entre
java 5 et java 1.4. Même quelque chose d'aussi incroyablement trivial
que récupérer la valeur d'une variable d'environnement ne *peut pas*
être fait de la même façon en java 1.4 et 5, où alors je suis
complètement à la masse. Il faut utiliser System.getenv() qui est
remis en java 5 mais qui est deprecated en java 1.4, et qui fait se
plaindre le compilateur.

Je ne parle pas le l'emmerdement absolument démentiel que produit
l'inclusion de jaxp dans la distribution standard, ce qui fait que
depuis les factory il est impossible de contrôler les processeurs XML
retournés, alors qu'ils sont parfois incompatibles. Je m'arrache les
cheveux là dessus.
c'est quoi ton pb

je suis passe de xerces au parseur standard du jdk qui est maintenant
integre sans aucune difficulte

par contre je suis assez d'accord avec leur warning a la con
sur les vector par exemple

Vector v=..
v.add(..)
il n'est pas d'accord et je l'emmerde non mais


--
des conneries j'en ai dites oui oui je vous assure...
mais elles n'engagent que votre perception
remy

Je vois, mais je trouve que ça à des avantages pratiques (séparer les
types de retour "normaux" des types dévolus à l'expression d'erreur).

Sauf qu'une exception n'est pas nécessairement une "erreur". Dans
une optique événementielle, "tout" est exception, par exemple :
clic, double-clic, événement clavier...

Dans la terminologie de java je ne crois pas que "tout" soit
exception.

Non, bien sûr. Mais le mécanisme d'exceptions est très utile dans le cadre
de la programmation événementielle, où "tout" est exception (un
gestionnaire de fenêtre, par ex).

Je ne vois pas le rapport avec ce qui précède en fait.

La phrase à laquelle je répondais est celle que j'ai gardée tout en haut
du post : tu sembles assimiler les exceptions en Java à une prise en
charge des erreurs. Une erreur est une exception, mais l'ensemble des
erreurs est plus petit que celui des exceptions. :-)


--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)

JKB <knatschke@koenigsberg.fr> writes:

Une fonction retourne quelque chose ou ne retourne rien.

D'où l'intérêt de différencier les sous-programmes comme le fait
Ada...

Une fonction renvoie toujours quelque chose et elle ne modifie
_jamais_ ses paramètres.

Quand on a un sous-programme qui ne renvoie rien, c'est une procédure,
qui peut éventuellement modifier ses paramètres.

Ces deux formes de sous-programmes correspondent à des cas
d'utilisation assez différents et ça évite les surprises.

A l'inverse, certains langages ont pris le parti pris de ne disposer
que de fonctions, lesquelles renvoient le résultat de la dernière
instruction par défaut. C'est sûr que c'est plus souple, mais cela
demande un peu plus d'attention pour éviter des pbs ennuyeux...

--
Eric Jacoboni, ne il y a 1450626910 secondes

c'est quoi ton pb
je suis passe de xerces au parseur standard du jdk qui est maintenant
integre sans aucune difficulte

Le problème c'est quand on veut faire tourner le même programme à des
endroits où il y a des jvm 1.4 et à d'autres où il y a des jvm
1.5. Les constructeurs de certains parseurs ont changé, ce qui fait
qu'on ne peut pas utiliser les mêmes versions des parseurs dans les
deux cas (il faut garder ensemble un couple factory /
implémentation). Tout ça c'est encore bénin, ça devient franchement
chiant quand je veux utiliser les factory de
javax.xml.transform.sax.TransformerHandler, et dès qu'on a besoin
d'instancier directement des classes dans les implémentations (par
exemple pour le moteur XPath de Xerces en 1.4 puisqu'il n'y a une
factory pour XPath qu'à partir de 1.5).

c'est quoi ton pb
je suis passe de xerces au parseur standard du jdk qui est maintenant
integre sans aucune difficulte

Le problème c'est quand on veut faire tourner le même programme à des
endroits où il y a des jvm 1.4 et à d'autres où il y a des jvm
1.5. Les constructeurs de certains parseurs ont changé, ce qui fait
qu'on ne peut pas utiliser les mêmes versions des parseurs dans les
deux cas (il faut garder ensemble un couple factory /
implémentation). Tout ça c'est encore bénin, ça devient franchement
chiant quand je veux utiliser les factory de
javax.xml.transform.sax.TransformerHandler, et dès qu'on a besoin
d'instancier directement des classes dans les implémentations (par
exemple pour le moteur XPath de Xerces en 1.4 puisqu'il n'y a une
factory pour XPath qu'à partir de 1.5).

le plus simple
mettre a jour toutes les mvj

le plus propre

public class MyTransformerHandlerImpl implements TransformerHandler
{
et tu codes ta propore fct
}

--
des conneries j'en ai dites oui oui je vous assure...
mais elles n'engagent que votre perception
remy

Je vois, mais je trouve que ça à des avantages pratiques (séparer les
types de retour "normaux" des types dévolus à l'expression d'erreur).

Sauf qu'une exception n'est pas nécessairement une "erreur". Dans
une optique événementielle, "tout" est exception, par exemple :
clic, double-clic, événement clavier...

Dans la terminologie de java je ne crois pas que "tout" soit
exception.

Non, bien sûr. Mais le mécanisme d'exceptions est très utile dans le
cadre de la programmation événementielle, où "tout" est exception (un
gestionnaire de fenêtre, par ex).

Vous voulez dire que dans les librairies pour faire des interfaces
graphiques, on utilise des exceptions pour communiquer l'action de
l'utilisateur ?

Je ne vois pas le rapport avec ce qui précède en fait.

La phrase à laquelle je répondais est celle que j'ai gardée tout en
haut du post : tu sembles assimiler les exceptions en Java à une
prise en charge des erreurs.

Ben oui... En fait je les ai jamais vu utilisées autrement.

Une erreur est une exception, mais l'ensemble
des erreurs est plus petit que celui des exceptions. :-)

Du point de vue des objets, Error et Exception sont des sous classes
de Throwable, donc les erreurs ne sont pas des exceptions. Mais ce
n'était sans doute pas votre point de vue.

SL wrote:

Je vois, mais je trouve que ça à des avantages pratiques (séparer les
types de retour "normaux" des types dévolus à l'expression d'erreur).
Sauf qu'une exception n'est pas nécessairement une "erreur". Dans

une optique événementielle, "tout" est exception, par exemple :
clic, double-clic, événement clavier...
Dans la terminologie de java je ne crois pas que "tout" soit

exception.
Non, bien sûr. Mais le mécanisme d'exceptions est très utile dans le

cadre de la programmation événementielle, où "tout" est exception (un
gestionnaire de fenêtre, par ex).

Vous voulez dire que dans les librairies pour faire des interfaces
graphiques, on utilise des exceptions pour communiquer l'action de
l'utilisateur ?

Enfin, c'est similaire, mais si on oublie de recuperer un evennement, il
se passe rien, alors qu'avec une exception, le programme peut se terminer.
Evidemment, ce qui change c'est surtout la semantique: l'evennement est
quelque chose de normal (le systeme ne doit pas dire "oh non
l'utilisateur a clique sur un bouton!"), alors que l'exception est
quelque chose ... d'exceptionnel (ce qui explique les abort en c++ sur
celles qui ne sont pas traitees).

On Tue, 9 May 2006, SL wrote:

La phrase à laquelle je répondais est celle que j'ai gardée tout en
haut du post : tu sembles assimiler les exceptions en Java à une
prise en charge des erreurs.

Ben oui... En fait je les ai jamais vu utilisées autrement.

Un exemple tout bête, qui peut être traité à partir d'exceptions :
dans un programme de téléchargement de pair à pair, si pour une raison
quelconque un des deux pairs déconnecte, on peut très bien faire remonter
une exception pour dire "attention, le pair n° 42 est parti !", et
diffuser l'information à partir d'exceptions propagées sur le réseau p2p.
Ce n'est pas forcément la meilleure façon de faire, mais ça permet à
quelqu'un qui possédait une certaine liste de téléchargements de ne pas
attendre "bêtement" un timeout en cherchant à contacter le n°43 qui n'est
plus là, et de chercher quelqu'un d'autre dans sa liste des pairs
possédant le fichier voulu.

Une erreur est une exception, mais l'ensemble
des erreurs est plus petit que celui des exceptions. :-)

Du point de vue des objets, Error et Exception sont des sous classes
de Throwable, donc les erreurs ne sont pas des exceptions. Mais ce
n'était sans doute pas votre point de vue.

Lorsque vous utilisez "IllegalArgumentException", vous traitez bien les
Exceptions comme des "erreurs", non ? Pourtant, on pourrait imaginer que,
en temps normal, le programme ait besoin d'un certain nombre d'arguments
pour fonctionner et qu'en pratique, il puisse arriver que l'on veuille le
faire tourner sans aucun argument. A ce moment-là, une exception est
levée, on rajoute un petit commentaire dans un fichier de log (par
exemple), et on continue sans tout bloquer. S'agissait-il réellement d'une
erreur ?

--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)

On Tue, 9 May 2006, SL wrote:

La phrase à laquelle je répondais est celle que j'ai gardée tout
en haut du post : tu sembles assimiler les exceptions en Java à
une prise en charge des erreurs.

Ben oui... En fait je les ai jamais vu utilisées autrement.

Un exemple tout bête, qui peut être traité à partir d'exceptions :
dans un programme de téléchargement de pair à pair, si pour une
raison quelconque un des deux pairs déconnecte, on peut très bien
faire remonter une exception pour dire "attention, le pair n° 42 est
parti !", et diffuser l'information à partir d'exceptions propagées
sur le réseau p2p. Ce n'est pas forcément la meilleure façon de
faire, mais ça permet à quelqu'un qui possédait une certaine liste
de téléchargements de ne pas attendre "bêtement" un timeout en
cherchant à contacter le n°43 qui n'est plus là, et de chercher
quelqu'un d'autre dans sa liste des pairs possédant le fichier
voulu.

Oui, je m'en serts aussi pour transmettre des informations qui ne sont
pas vraimetn des erreurs, mais je pensais qu'il ne fallait pas s'en
vanter. Je pensais qu'une exception était censée n'être levée que
lorsque le programme se trouve dans un état "non souhaitable". Par
exemple, /Java in a nutshell/, 4ème édition, p. 56 : « Exceptions that
are subclasses of Error generally indicate uncoreverable problems
[...] Exception that are subclasses of Exception, on the other hand,
indicate *less severe condition* ». Mais effectivement dans la javadoc
rien ne dit pour la classe Exception que c'est un état non
souhaitable. Bigre.

Une erreur est une exception, mais l'ensemble des erreurs est plus
petit que celui des exceptions. :-)

Du point de vue des objets, Error et Exception sont des sous
classes de Throwable, donc les erreurs ne sont pas des
exceptions. Mais ce n'était sans doute pas votre point de vue.

Lorsque vous utilisez "IllegalArgumentException", vous traitez bien
les Exceptions comme des "erreurs", non ? Pourtant, on pourrait
imaginer que, en temps normal, le programme ait besoin d'un certain
nombre d'arguments pour fonctionner et qu'en pratique, il puisse
arriver que l'on veuille le faire tourner sans aucun argument. A ce
moment-là, une exception est levée, on rajoute un petit commentaire
dans un fichier de log (par exemple), et on continue sans tout
bloquer. S'agissait-il réellement d'une erreur ?

Je dirais que oui :-) IllegalArgumentException indique dans tous les
cas qu'un contrat a été rompu, fût-ce au niveau très local d'une
methode, et même si au niveau de l'ensemble du programme c'est un état
parfaitement pris en compte. Elle est définie comme :

Thrown to indicate that a method has been passed an illegal or
inappropriate argument.

On remarque donc deux occurrences du morphème "in-" (il- et in-), qui
donne une connotation indubitablement négative ou non souhaité à la
situation décrite :-) (désolé pour la cuistrerie)