Microsoft et Java

Le 22/06/2011 16:07, NiKo a écrit :

Le 23/06/2011 16:02, Toxico Nimbus a écrit :

Euh ! Tu sais qu'on est aujourd'hui le 22 juin et non le 23 ?

Merci

--
Toxico Nimbus

On 22 juin, 13:09, JKB <j...@koenigsberg.invalid> wrote:

Le Wed, 22 Jun 2011 01:59:12 -0700 (PDT),
Aeris Imirhil <aeris.imir...@gmail.com> écrivait :


> Dans l'exemple précédent, elle nécessite la connaissance du code de la
> fonction « writeToFile » et l'analyse de toutes les valeurs de retour
> possibles.

        Non. Elle nécessite de connaître le prototype de la f onction. Point
        barre. Et en Java, si tu ne connais pas le prototype d'un e fonction,
        tu ne vas pas loin non plus.

Mais si voyon, l'IDE est là pour le connaitre à ta place. Pas encore
compris ça ?
En Java, tout est dans l'IDE.

On 23 juin, 16:02, Toxico Nimbus <T...@free.fr> wrote:

Comme dans tous les langages, c'est la documentation compl te de
l'interaction de la fonction/m thode avec son environnement d' x cution
(arguments, valeur de retour, exceptions, variables globales modifi es,
etc).

Qui, en faisant l'hypothèse que le développeur est mauvais, pue très
fortement.
Et même avec de bons devs, en cours de dev, est très fortement
parcellaire.

Comment d finis-tu un bug ? Pour moi c'est quand le fonctionnement n'est
pas conforme celui qui est pr vu dans la documentation.

Un bug pour moi est que la fonction ne fasse pas ce qu'on attend
d'elle dans le cas nominal, mais aussi qu'elle plante dans les cas
hors limite.

Pour moi, la documentation n'est pas un élément viable.
Elle sert essentiellement au début du projet pour comprendre le
fonctionnement global d'une lib et ses principes généraux. Mais je ne
m'en servirais pas comme unique hypothèse que mon code est correct et
fiable.
La doc peut elle aussi être buggée ou non fiable et ne peut donc pas
servir d'élément de preuve.

Les exceptions, elles, sont des éléments fiables, puisque le
compilateur me garantit qu'aucune exception autre que celles déclarées
ne peut se produire, quelque soit la correction du code ou de la doc.

Si tu ne sais pas en quoi consiste l'exception, tu ne sais pas quoi en
faire.

Je ne sais peut-être pas quoi en faire, mais je sais au moins protéger
mon programme contre elle.
En C, si un cas alternatif d'erreur a été mis dans le code mais ne se
trouve ni dans le prototype ni dans l'interface (erreur du dev,
fainéantise, manque de temps…), ton code résultant est non fiable car
peut laisser passer des erreurs.

> Je fais comment avec ta macro pour traiter diff remment l'absence de
> fichier et le crash disque, et pour en avertir diff remment
> l'utilisateur ?

man errno

Et le code devient imbouffable…
Ne serait-ce que pour penser renseigner cette variable dans chaque cas
d'erreur…

Et quand je lis des choses comme « Parfois, si -1 est une valeur de
retour légale, il faut positionner errno à 0 avant d'effectuer l'appel
système, de manière à détecter une erreur éventuelle. », ça n e me
rassure pas sur sa fiabilité ni sur la propreté du code…

Sans parler que le problème reste le même : errno t'a retourné une
fois -2 et une fois -3, qui te *garantit* qu'il n'y a aucune
possibilité d'obtenir -4 à un moment ?

Le 22/06/2011 16:59, Aeris Imirhil a écrit :

On 23 juin, 16:02, Toxico Nimbus<T...@free.fr> wrote:

Comme dans tous les langages, c'est la documentation compl te de
l'interaction de la fonction/m thode avec son environnement d' x cution
(arguments, valeur de retour, exceptions, variables globales modifi es,
etc).

Qui, en faisant l'hypothèse que le développeur est mauvais, pue très
fortement.

Moi je ne fais pas ce genre d'hypothèse, c'est assez stérile.

Et même avec de bons devs, en cours de dev, est très fortement
parcellaire.

Une API mal documentée est rarement bien écrite. Un dev qui bâcle sa doc
aura sons doute déjà bâclé ses commenté, son code, sa conception.

Comment d finis-tu un bug ? Pour moi c'est quand le fonctionnement n'est
pas conforme celui qui est pr vu dans la documentation.

Un bug pour moi est que la fonction ne fasse pas ce qu'on attend
d'elle dans le cas nominal, mais aussi qu'elle plante dans les cas
hors limite.

1. Ce qu'on attend d'elle ne peut se trouver ailleurs que dans la doc.

2. Je ne vois pas ce qu'est un cas hors limite, à part peut-être une
méthode/classe utilisée en dehors de son domaine de validité ?

Pour moi, la documentation n'est pas un élément viable.
Elle sert essentiellement au début du projet pour comprendre le
fonctionnement global d'une lib et ses principes généraux. Mais je ne
m'en servirais pas comme unique hypothèse que mon code est correct et
fiable.
La doc peut elle aussi être buggée ou non fiable et ne peut donc pas
servir d'élément de preuve.

Gnî ? Tu sors ta boule de cristal, ou tu décide à la place du concepteur
ce que doit faire telle ou telle fonction ?

Les exceptions, elles, sont des éléments fiables, puisque le
compilateur me garantit qu'aucune exception autre que celles déclarées
ne peut se produire, quelque soit la correction du code ou de la doc.

Oui, ça me semble évident.

Si tu ne sais pas en quoi consiste l'exception, tu ne sais pas quoi en
faire.

Je ne sais peut-être pas quoi en faire, mais je sais au moins protéger
mon programme contre elle.

Pas forcément si tu ne sais pas dans quel état est le système quand elle
est levée. Il n'y a que le concepteur qui peut te le dire, ou alors il
faut relire les sources de ta lib.

En C, si un cas alternatif d'erreur a été mis dans le code mais ne se
trouve ni dans le prototype ni dans l'interface (erreur du dev,
fainéantise, manque de temps…), ton code résultant est non fiable car
peut laisser passer des erreurs.

c'est le default du switch, ça ne vaut pas mieux qu'avec des exceptions.

Je fais comment avec ta macro pour traiter diff remment l'absence de
fichier et le crash disque, et pour en avertir diff remment
l'utilisateur ?

man errno

Et le code devient imbouffable…
Ne serait-ce que pour penser renseigner cette variable dans chaque cas
d'erreur…

C'est la macro qui s'en occupe.

Et quand je lis des choses comme « Parfois, si -1 est une valeur de
retour légale, il faut positionner errno à 0 avant d'effectuer l'appel
système, de manière à détecter une erreur éventuelle. », ça ne me
rassure pas sur sa fiabilité ni sur la propreté du code…

Oui, je sais, c'est mal.

Sans parler que le problème reste le même : errno t'a retourné une
fois -2 et une fois -3, qui te *garantit* qu'il n'y a aucune
possibilité d'obtenir -4 à un moment ?

c'est le default du switch. Par ailleurs toutes les valeurs de errno
forment partie du standard POSIX, donc c'est assez peu sujet à
changement. Sinon c'est "erreur inconnue".

--
Toxico Nimbus

On Mon, 20 Jun 2011 22:42:16 +0200, Aéris wrote:

Il y en a surtout une qui avantage énormément les GC : les mecs de chez
Sun, Oracle ou IBM sont bien plus compétents que nous pour savoir
comment gérer (proprement si possible) la mémoire.

Et merde, tu viens de baisser le niveau de l'équipe qui est ici.
Prends le temps de faire des recherches sur tes correspondants.
C'est pratique quand on poste avec son vrai nom. Pas comme toi.

On 22 juin, 17:19, Toxico Nimbus <T...@free.fr> wrote:

> Qui, en faisant l'hypoth se que le d veloppeur est mauvais, pue tr s
> fortement.

Moi je ne fais pas ce genre d'hypoth se, c'est assez st rile.

Je ne la fait pas non plus, je fais justement l'hypothèse que mon code
ne doit faire aucune hypothèse sur ce qui se trouve en dessous.

Une API mal document e est rarement bien crite. Un dev qui b cle sa doc
aura sons doute d j b cl ses comment , son code, sa conception.

Je parle du moment où tu es encore en développement et où tu intègr es
des morceaux de code d'autres développeurs de ton équipe.
Tu as rarement de la doc fiable à ce moment du projet, au mieux la
Javadoc dans le code.

1. Ce qu'on attend d'elle ne peut se trouver ailleurs que dans la doc.

Dans la spécification oui, mais celle-ci n'est pas orientée technique
ni développement.
Dans la doc finale, elle y sera sûrement, mais elle n'est souvent pas
disponible au moment où on en a besoin (en cours de dev).

2. Je ne vois pas ce qu'est un cas hors limite, part peut- tre une
m thode/classe utilis e en dehors de son domaine de validit ?

Voila.
Dans le domaine sécuritaire, même si l'utilisateur saisie n'importe
quoi, le soft ne doit pas faire n'importe quoi et se comporter
correctement.
Dans l'exemple de la fraiseuse, même si l'utilisateur saisit « toto  »
ou « -1 » en vitesse de rotation, le soft doit arrêter l'avance de
coupe dès que le moteur de rotation s'arrête (certes le contrôle des
données sera fait avant, mais cela est un exemple). Si tu as un bug
dans ton code, tu pourrais très bien envoyé -1 au moteur de commande,
qui va te bouffer une grosse « exception » ou un code d'erreur. Si
cette « exception » n'a pas été vue (uniquement possible en C e t pas
en Java), ta machine va continuer à exécuter son programme, au lieu de
partir en arrêt d'urgence pour couper tous les moteurs. Et tu vas
usiner moteur de coupe arrêté…

Gn ? Tu sors ta boule de cristal, ou tu d cide la place du concepteur
ce que doit faire telle ou telle fonction ?

La doc me sert à savoir ce qu'elle fait dans le cas nominal.
Pour la gestion des cas hors limite, je ne me fie qu'à moi-même et ne
fait aucune hypothèse : si la fonction lève une exception, je la
traite, même si je ne comprend pas (encore) ce qu'elle fait. Question
de sécurité. Le développeur a très bien pu oublier de mettre sa doc ou
javadoc à jour.

> Je ne sais peut- tre pas quoi en faire, mais je sais au moins prot ger
> mon programme contre elle.

Pas forc ment si tu ne sais pas dans quel tat est le syst me quand elle
est lev e. Il n'y a que le concepteur qui peut te le dire, ou alors il
faut relire les sources de ta lib.

J'ai au moins la possibilité de partir en mode « alerte rouge ».
Et je suis au moins averti qu'il manque un truc dans la doc et je peux
faire le nécessaire pour me renseigné.
Le but est d'au moins être averti du problème au plus tôt, alors que
l'erreur va sûrement passer aux oubliettes en C, faute de détection.

> En C, si un cas alternatif d'erreur a t mis dans le code mais ne se
> trouve ni dans le prototype ni dans l'interface (erreur du dev,
> fain antise, manque de temps ), ton code r sultant est non fiable car
> peut laisser passer des erreurs.

c'est le default du switch, a ne vaut pas mieux qu'avec des exceptions.

Les exceptions n'ont pas ce problème.
Si un cas alternatif est dans le code mais pas dans la doc,
l'exception est obligatoirement déclarée dans le prototype (sinon la
lib n'aurait pas pu être compilée) et sera donc signalée à la
compilation.

Par ailleurs toutes les valeurs de errno
forment partie du standard POSIX, donc c'est assez peu sujet
changement. Sinon c'est "erreur inconnue".

Et donc je ne peux pas gérer d'erreur custom, comme les erreurs
métiers…
Et même au niveau le plus haut…

Le Wed, 22 Jun 2011 15:35:06 +0000 (UTC),
Mihamina Rakotomandimby (R12y) <mihamina@rktmb.org> écrivait :

On Mon, 20 Jun 2011 22:42:16 +0200, Aéris wrote:

Il y en a surtout une qui avantage énormément les GC : les mecs de chez
Sun, Oracle ou IBM sont bien plus compétents que nous pour savoir
comment gérer (proprement si possible) la mémoire.

Et merde, tu viens de baisser le niveau de l'équipe qui est ici.
Prends le temps de faire des recherches sur tes correspondants.
C'est pratique quand on poste avec son vrai nom. Pas comme toi.

D'un autre côté, c'est reposant. S'il se renseignait un minimum, il
tomberait peut-être de son piédestal ;-)

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr

On 22 juin, 17:35, "Mihamina Rakotomandimby (R12y)"
<miham...@rktmb.org> wrote:

On Mon, 20 Jun 2011 22:42:16 +0200, Aéris wrote:
> Il y en a surtout une qui avantage énormément les GC : les mecs de chez
> Sun, Oracle ou IBM sont bien plus compétents que nous pour savoir
> comment gérer (proprement si possible) la mémoire.

Et merde, tu viens de baisser le niveau de l'équipe qui est ici.
Prends le temps de faire des recherches sur tes correspondants.
C'est pratique quand on poste avec son vrai nom. Pas comme toi.

Comprendre le « nous » au sens « le commun des développeurs ».
J'ai jamais dis qu'il n'y avait pas d'exception à la règle, mais une
discussion est centrée autour du « développeur moyen », pas « de la
dreamteam de dev »

Quand à mon véritable nom, je pense que tu pourras le trouver
facilement =)

On 22 juin, 17:35, "Mihamina Rakotomandimby (R12y)"
<miham...@rktmb.org> wrote:

On Mon, 20 Jun 2011 22:42:16 +0200, Aéris wrote:
> Il y en a surtout une qui avantage énormément les GC : les mecs de chez
> Sun, Oracle ou IBM sont bien plus compétents que nous pour savoir
> comment gérer (proprement si possible) la mémoire.

Et merde, tu viens de baisser le niveau de l'équipe qui est ici.
Prends le temps de faire des recherches sur tes correspondants.
C'est pratique quand on poste avec son vrai nom. Pas comme toi.

J'ajouterais que même si je ne vous connais pas particulièrement ni
vos niveaux de compétence, quelque soit mon niveau, je n'oserais
jamais prétendre être meilleurs que IBM, Oracle ou Sun…

witch(ios = bar())

Arrière, sorcière !