[blabla@olympe] Le topic du modo, dieu de la fibre et du monde

Recherche :

Sujet(s) à lire :
- Who's who@Programmation

Mot : Pseudo : Filtrer Aller à la page :
Page : 1 2 3 4 5 .. 17885 17886 17887 .. 27000 27001 27002 27003 27004 27005 Page Suivante Page Précédente Bas de page
Auteur	Sujet : [blabla@olympe] Le topic du modo, dieu de la fibre et du monde

sligor

Reprise du message précédent :
tu as l'air de vachement t'y connaître
espèce de drogué [:peronnelle]

Message cité 1 fois

---------------
qwerty-fr

Publicité

el muchacho

Comfortably Numb

J'édite ce post au fur et à mesure, c'est chiant les quotes....

Un Programmeur a écrit :

Mon problème est qu'on vérifie statiquement quelque chose dont je vois mal
l'utilité, et pas ce dont je vois l'utilité: la possibilité ou non d'avoir
une exception. Tant que je n'ai pas à la traiter, je me fous de
l'exception qu'une routine peut lancer.

C'est vrai dans une application dont tu connais la finalité, mais pas dans du code réutilisable ou une librairie, où tu ne sais pas à l'avance ce que va faire l'utilisateur d'une exception que ta lib lève et qu'il peut traiter, c'est à lui de décider de la traiter ou non. Donc tu dois lui présenter toutes les exceptions que ton code est susceptible de remonter et qu'il peut traiter pour qu'il décide quoi en faire.

Citation :

Non, en pratique, on n'est pas obligé de modifier toutes les couches
intermédiaires. On se contenter de modifier les appelants qui les
catcheront pour lancer une exception plus générale, un wrapper de type
"MyLayerException" qui contient l'exception d'origine, et c'est ce wrapper
qu'on va retrouver dans toute la couche.

En pratique, on met en place dès le départ un mécanisme qui permet de
contourner la vérification statique au prix d'un certain boulot réparti sur
toute la durée de vie du machin.

C'est pas faux en ce qui concerne notre code applicatif qaund on veut pas se faire chier, mais en ce qui concerne le code de la plupart des librairies, que ce soit la librairie standard ou les libs open source un tant soit peu soigneusement écrites, ça n'est pas le cas. Je veux dire, par exemple, la JDK contient de nombreuses hiérarchies de classes, définit une chiée d'exceptions et ne les wrappe pas en JDKException. Et elles sont au final très utiles.

Citation :

Tout ce qui est intéressant tant que tu ne dois pas traiter l'exception est
"est-ce qu'une exception est possible ou pas?". Si la réponse est "oui",
alors tu dois te demander quelles sont les postconditions en présence de
l'exception.

Mais comment fais-tu pour savoir si le code que tu appelles balance des exceptions s'il ne les déclare pas ?

Citation :

Au final, dans la pratique, le système de gestion des exceptions
aidé par le compilateur est un système très sûr. Infiniment plus qu'en
C++. La gestion des erreurs est même l'un des aspects les plus réussis de
Java et je pense l'un des moins décriés du langage.

Qu'est-ce qu'il t'offre comme sécurité qu'une vérification statique de
throw/nothrow ne te donnerait pas? (J'ai aucune expérience avec Java, je
vois bien ce que m'aurait couté un mécanisme similaire mais même si j'ai
l'impression qu'il m'aurait peu apporté -- j'ai pas le souvenir de
problèmes qu'un tel mécanisme aurait empéché ou du moins permi de résoudre
beaucoup plus facilement -- , j'ai assez d'expérience pour
savoir qu'il y a des facilités qu'il faut avoir eue pour en voir l'intérêt)

Je ne me souviens plus de l'usage de throw/nothrow. Tu peux me rafraichir la mémoire ?

Citation :

Un Programmeur a écrit :

Dans la pratique de masklinn Très honnêtement, je ne vois pas de quoi il
parle quand il dit que c'est "super merdique".

C'est pas le premier que je vois dire cela.

Ah [:spamafote]

Joel F a écrit :

Citation :

J'ai du mal à imaginer un type de code que je ne mettrai sous aucune
condition sous forme de template. Et je suis moins porté que d'autres sur
les templates, Joel F pour ne pas chercher plus loin que ces forums doit
les utiliser encore plus facilement que moi.

Y a du coup ou, pour des raisons de bloat ou de taille d'executable, tu vas eviter ou
du moins slicer de façon à ne templatiser que la partie vraiment générique. Après c'ets comem toujours,
quand tu as appris à te servir d'un amrteau, tout ressemble à un clou.

Voila.

Message cité 4 fois
Message édité par el muchacho le 31-07-2010 à 15:28:30

---------------
Les aéroports où il fait bon attendre, voila un topic qu'il est bien

Joel F

Real men use unique_ptr

el muchacho a écrit :

Voila.

En fait, t'apprend à etre minimaliste sur les templates des que tu intuite bien le Generic Programming à la stepanov & gregor.
La tu t'aperçois que tu ne fait des *classes* templates que lorsque oui, leur parametrage est nécessaire (genre vector ou autre truc ou la généricité de type est nécéssaire ou bien si le tempalte te permet de pas te casser le cul sur une interface chelou). Le reste de généricité est surtout géré par des fonctions tempaltes avec surcharges ou tag-dispatching.

Message cité 1 fois
Message édité par Joel F le 31-07-2010 à 14:02:49

mareek

Et de 3 \o/

el muchacho a écrit :

Non, la loi et la spec oblige le fournisseur à fournir une version du mouchard installable "facilement" sur les OS libres. En pratique, le plus simple est de le faire faire par les FAI pour qu'ils l'intègrent dans leur box par une simple mise à jour en ligne.

Ni la loi, ni les décrets d'application ne font référence a un quelconque mouchard, ils parlent juste de "moyen de sécurisation de l'accès a internet" recommandé par la commission de protection des droits APRES que cette dernière ait constaté un téléchargement illégal sur cet accès a internet. [:aloy]

cf : http://www.maitre-eolas.fr/post/20 [...] z-continue

Message cité 1 fois

---------------
"I wonder if the internal negative pressure in self pumping toothpaste tubes is adjusted for different market altitudes." John Carmack

el muchacho

Comfortably Numb

Joel F a écrit :

Sans avoir ton expérience ni même probablement celle d'un Prog en C++, c'est effectivement ce que je pense intuitivement, du moins pour le C++.

mareek a écrit :

Ouais, ch'uis pas trop versé dans la loi (dans les lois en général.

Citation :

La HADOPI proprement dite ne nous intéresse pas. Sans vouloir vexer ses membres, elle ne sert à rien.

[:ddr555] impayable, ce maître Eolas

Message édité par el muchacho le 31-07-2010 à 15:17:06

---------------
Les aéroports où il fait bon attendre, voila un topic qu'il est bien

Un Programmeur

el muchacho a écrit :

J'édite ce post au fur et à mesure, c'est chiant les quotes....

Tu peux indiquer quand c'est terminé? J'ai commencer à répondre et voilà que tu te remets à éditer.

Message cité 1 fois

---------------
The truth is rarely pure and never simple (Oscar Wilde)

el muchacho

Comfortably Numb

Un Programmeur a écrit :

Tu peux indiquer quand c'est terminé? J'ai commencer à répondre et voilà que tu te remets à éditer.

Ah non là c'est terminé depuis longtemps.

Message cité 1 fois

---------------
Les aéroports où il fait bon attendre, voila un topic qu'il est bien

el muchacho

Comfortably Numb

Et merde, j'ai oublié mon rdv chez le coiffeur

---------------
Les aéroports où il fait bon attendre, voila un topic qu'il est bien

mareek

Et de 3 \o/

el muchacho a écrit :

Ah non là c'est terminé depuis longtemps.

t'as essayé d'utiliser ça: ?

Message cité 1 fois

---------------
"I wonder if the internal negative pressure in self pumping toothpaste tubes is adjusted for different market altitudes." John Carmack

Jubijub

Parce que je le VD bien

Un Programmeur a écrit :

Ou j'ai rien compris, ou ça implique d'avoir un wrapper (et donc pas de
laisser simplement remonter les exceptions), ou tu as pour tout les niveaux
intermédiaires une spécification d'exceptions qui contient les exceptions
possibles.

ben comme l'a dit muchacho : en général il est de coutume de faire un wrapper pour ses propres exceptions. Donc in fine, quand tu regarde la stacktrace, tu peux voir du MyException, du API1Exception, API2Exception, etc...c'est souvent plus parlant que de voir juste une NullPointerException, parce que tu peux rajouter un peu de contexte au moment où tu catch l'exception

sinon tu n'es pas obligé de wrapper, toutes les Exceptions descendant de Exception, il te suffit de mettre un try/Catch sur Exception et t'es sur d'avoir une voiture balais qui te remonte toutes les exceptions. Ca se fait beaucoup en dev web, parce qu'une erreur que tu laisses péter dans le container te renvoit en général une erreur 500, avoir un catchall te permet de rediriger vers une page d'erreur un peu plus propre voire plus explicite (qui te permet au moins d'afficher à l'utilisateur un code erreur ou autre, ça sert vachement pour le support derrière)

---------------
Jubi Photos : Flickr - 500px

Publicité

Un Programmeur

Bon, je vais reprendre mon point de vue parce que j'ai l'impression que je
n'ai pas été clair. D'autant plus que la pratique que vous décrivez me
semble plutôt apporter de l'eau à mon moulin qu'autre chose.

J'ai un a priori (je ne les ai jamais utilisées) contre les spécifications
d'exception en général (qu'elles soient vérifiées statiquement ou non
d'ailleurs) autre qu'un simple choix binaire: la routine peut lancer une
exception ou non (ce que j'ai appelé throw/nothrow dans mes messages
précédants et dans la suite).

Cet a priori a trois sources (complètement indépendantes du langage):

- je ne me souviens pas avoir eu de bug pour lequel je me suis dit "si on
avait un langage avec des spécifications d'exceptions, le problème n'aurait
jamais eu lieu/aurait été beaucoup plus simple à débugger". Autrement dit,
si je vois bien un certain intérêt théorique, les effets pratiques me
semblent faibles.

- les spécifications d'exception me se semble être lourde à maintenir.
Vous avez l'air d'être d'accord en proposant des techniques (usage de
wrappers et spécification d'exceptions très hautes dans la hiérarchie) qui
à mon sens reviennent à perdre la spécification d'exception autre que
celles apportées par throw/nothrow tout en nécessitant, au moins pour les
wrappers, une certaine maintenance.

- je n'ai vu aucune proposition de mécanismes viables pour arriver à
maintenir autre chose que throw/nothrow en présence de polymorphisme
paramétrique.

Petite note sur le C++. C++03 a des spécifications d'exceptions vérifiées
dynamiquement. Les bonnes pratiques demandent de ne pas les utiliser pour
plus que throw/nothrow. C++0X a un autre mécanisme pour throw/nothrow plus
pratique pour les templates, vérifié dynamiquement et déprécie les
spécifications d'exceptions.

el muchacho a écrit :

Jubijub a écrit :

C'est vrai dans une application dont tu connais la finalité, mais pas dans
du code réutilisable ou une librairie, où tu ne sais pas à l'avance ce que
va faire l'utilisateur d'une exception que ta lib lève et qu'il peut
traiter, c'est à lui de décider de la traiter ou non. Donc tu dois lui
présenter toutes les exceptions que ton code est susceptible de remonter
et qu'il peut traiter pour qu'il décide quoi en faire.

Le point ici est propre à Java. Le fait qu'il y ait des exceptions qui
n'apparaissent pas dans les spécifications d'exceptions empèche de savoir
si une routine est nothrow à partir des mécanismes du langage (on peut
toujours utiliser des commentaires).

Citation :

Ah, wrapper des exceptions. Ce raisonnement de mon point de vue est: on a
des vérifications statiques d'exception mais on wrappe en perdant donc
l'info qui est sensée être vérifiée statiquement. Et en prime, il faut
l'avoir prévu avant que ce ne soit nécessaire. Donc je reformule ton point
de vue (voir ma signature avant de prendre la reformulation trop au
sérieux):

En pratique, on met en place dès le départ un mécanisme qui permet de
contourner la vérification statique au prix d'un certain boulot réparti sur
toute la durée de vie du machin.

C'est pas faux en ce qui concerne notre code applicatif qaund on veut pas
se faire chier, mais en ce qui concerne le code de la plupart des
librairies, que ce soit la librairie standard ou les libs open source un
tant soit peu soigneusement écrites, ça n'est pas le cas. Je veux dire, par
exemple, la JDK contient de nombreuses hiérarchies de classes, définit une
chiée d'exceptions et ne les wrappe pas en JDKException. Et elles sont au
final très utiles.

Une couche en dessous jette une exception. Ou je la traite ou je la
transmet. Si j'ai à la traiter, oui il faut que je la connaisse. Si je me
contente de la transmettre, j'ai pas envie d'éditer ma fonction simplement
parce que la couche en dessous lance un ensemble différent d'exceptions.

Ma compréhension de la pratique suggérée est que quand une couche transmet
une exception, elle ne la laisse pas telle quelle (pour éviter justement de
devoir modifier toutes les spécifications d'exception de ses fonctions et
dans les couches appelantes) mais la wrappe dans une classe
PassedThroughException. Cet usage me semble au final équivalent à
throw/nothrow (dés qu'une exception est possible, on aura
PassedThroughException, je ne vois pas l'info qu'on a en plus qu'avec
simplement un throw) avec du boulot en plus (l'encapsulation).

Citation :

Mais comment fais-tu pour savoir si le code que tu appelles balance des
exceptions s'il ne les déclare pas ?

On peut documenter... l'avantage de la documentation est qu'elle peut ne
pas être précise. En général, tout ce qui n'est pas conçu explicitement
pour ne pas jeter d'exception peut en jeter et c'est tout ce qui
m'importe. Les points où il faut intercepter les exceptions et ne pas les
transmettre sont tout compte fait rares(*).

Citation :

[quotemsg]

Au final, dans la pratique, le système de gestion des exceptions
aidé par le compilateur est un système très sûr. Infiniment plus qu'en
C++. La gestion des erreurs est même l'un des aspects les plus réussis de
Java et je pense l'un des moins décriés du langage.

Je ne me souviens plus de l'usage de throw/nothrow. Tu peux me rafraichir
la mémoire?

[/quotemsg]

Je ne suis pour une annotation throw/nothrow des routines et la validation
statique de ces annotations (permettant d'annoter throw quelque chose qui
en pratique est nothrow mais pas l'inverse). Des spécifications
d'exceptions plus complexes ne me semble rien apporter de plus avec un coût
certain.

Citation :

[quotemsg]

J'ai du mal à imaginer un type de code que je ne mettrai sous aucune
condition sous forme de template. Et je suis moins porté que d'autres sur
les templates, Joel F pour ne pas chercher plus loin que ces forums doit
les utiliser encore plus facilement que moi.

Y a du coup ou, pour des raisons de bloat ou de taille d'executable, tu vas
eviter ou du moins slicer de façon à ne templatiser que la partie vraiment
générique. Après c'ets comem toujours, quand tu as appris à te servir d'un
amrteau, tout ressemble à un clou.

Voila.

[/quotemsg]

Je suis d'accord avec la remarque de Joel, mais je ne vois pas le rapport
avec les spécifications d'exceptions. (Je l'avais pris comme une remarque,
un début de digression, mais ton simple commentaire "voilà" me laisse
croire que tu y vois autre chose).

(*) Je me demande si l'usage en Java n'est pas d'utiliser des exceptions dans des
contextes où je ne le ferai pas en C++.

Message édité par Un Programmeur le 31-07-2010 à 18:40:32

---------------
The truth is rarely pure and never simple (Oscar Wilde)

el muchacho

Comfortably Numb

mareek a écrit :

t'as essayé d'utiliser ça: http://forum-images.hardware.fr/th [...] quote+.gif ?

Quoi ? c'est quoi ce bouton ? [:pingouino] pas vu.

Message cité 1 fois

---------------
Les aéroports où il fait bon attendre, voila un topic qu'il est bien

zapan666

Tout est relatif

el muchacho a écrit :

Quoi ? c'est quoi ce bouton ? [:pingouino] pas vu.

ça dépend de ton thème hfr.
("Ajouter à la liste des messages cités" )

Message édité par zapan666 le 31-07-2010 à 20:17:40

---------------
my flick r - Just Tab it !

el muchacho

Comfortably Numb

Je ne sais pas si c'est maintenant le cas aussi pour le C++, mais en Java en tout cas, la gestion d'exceptions ne demande pas vraiment d'effort: quand l'éditeur voit qu'une méthode déclare une exception X, il propose automatiquement:
- soit d'entourer l'appel par un bloc try{...}catch(X){...}
- soit d'ajouter une clause catch(X){...} à un bloc try{...} existant
- soit d'ajouter une clause throws X à la signature de la méthode que l'on écrit.
Quand on écrit un new X(), l'éditeur propose d'ajouter automatiquement throws X à la signature (de toute façon on n'a pas le choix, sinon le compilo couine). Et bien sur il propose aussi d'ajouter une entrée pour décrire l'exception dans la Javadoc de la méthode.
C'est très confortable et ça oblige à traiter tous les cas. Il ne reste plus qu'à documenter les causes de ces exceptions, et bien sûr, c'est là que le code pêche le plus: la doc. Mais au moins, un codeur qui passe derrière sait que la méthode throws X et devra en tenir compte, soit en la chopant, soit en la laissant passer.

Du coup, en théorie, les specs d'exceptions sont lourdes à maintenir, mais en pratique, ce n'est pas mon impression. S'il y a du refactoring à faire (encore une fois entièrement automatisé par l'IDE, donc autrement plus confortable qu'en C++), c'est rarement au niveau des exceptions pour la bonne raison que les sources d'exceptions applicatives ne changent pas (absence de fichier, connexion foireuse, etc), mais plutôt du renommage ou l'ajout ou la suppression d'un argument à une méthode.

Je ne pense pas qu'on puisse se fier aux dévs pour documenter toutes les API qu'ils développent. De mon souvenir, en C++, dans une appli où les devs n'étaient pas très rigoureux, on pouvait se retrouver avec des exceptions qui pétaient au plus haut niveau sans qu'on ne soit plus capable d'en déterminer la provenance exacte. Tout ça parce que le développeur avait plus ou moins caché l'exception sous le tapis et/ou qu'aucune couche intermédiaire ne la traitait. C'est je pense un peu l'équivalent de ne pas traiter tous les codes d'erreur en retour d'une fonction C. C'est ce type de situation qu'on évite assez facilement en Java. Le fait que les exceptions Java, même wrappées, conservent toute la Stacktrace depuis leur origine est en outre une bouée de sauvetage vitale pour les exceptions runtime, notamment.

Voila, je ne suis p-ê pas très convaincant, mais je me base sur mes propres expériences des deux langages. Après l'expérience d'autres personnes peut être différente.

Message cité 3 fois
Message édité par el muchacho le 31-07-2010 à 22:09:34

---------------
Les aéroports où il fait bon attendre, voila un topic qu'il est bien

Joel F

Real men use unique_ptr

je t'avouerais que ca fait des années que j'ai pas *écris* de code avec des exceptions mais plutot du code exception-safe par design. Par contre, réutiliser du code existant, spa la meme chose

Message cité 1 fois

Jubijub

Parce que je le VD bien

dernz

---------------
Jubi Photos : Flickr - 500px

Loom the Gloom

Even coders get the blues...

prems [:banguy]

---------------
Music|Market|Feed|Loom|DVD

vapeur_cochonne

Stig de Loisir

dodo ²

---------------
marilou repose sous la neige

kadreg

profil: Utilisateur

coin coin

---------------
brisez les rêves des gens, il en restera toujours quelque chose... -- laissez moi troller sur discu !

zapan666

Tout est relatif

le dernier Dilbert [:bien]

---------------
my flick r - Just Tab it !

el muchacho

Comfortably Numb

<papys>Ca marche pas, hi hi hi</papys>

La pub pour le câble [:rofl]

Epic fail

Message édité par el muchacho le 01-08-2010 à 10:33:17

---------------
Les aéroports où il fait bon attendre, voila un topic qu'il est bien

koskoz

They see me trollin they hatin

sligor a écrit :

tu as l'air de vachement t'y connaître
espèce de drogué [:peronnelle]

Je regarde de nombreux documentaires [:cosmoschtroumpf]

Message édité par koskoz le 01-08-2010 à 10:33:27

---------------
Twitter

koskoz

They see me trollin they hatin

Un type, marcel gris, stationné en bas de chez moi, qui est dans son AX, porte ouverte, Johnny dans le poste, sa 3ème clope en bouche, depuis 40min [:le kneu]

Message cité 1 fois
Message édité par koskoz le 01-08-2010 à 10:44:03

---------------
Twitter

Dj YeLL

$question = $to_be || !$to_be;

koskoz a écrit :

Un type, marcel gris, stationné en bas de chez moi, qui est dans son AX, porte ouverte, Johnny dans le poste, sa 3ème clope en bouche, depuis 40min [:le kneu]

Enjoy.

---------------
Gamertag: CoteBlack YeLL

theredled

● REC

C'est le standard dans mon quartier

---------------
Contes de fées en yaourt --- █ --- zed, souviens-toi de ma dernière lettre. --- Rate ta musique

___alt

Monde de merde.
Want my holidays back.

Message cité 1 fois

---------------
TRIPS RIGHT BUNCH F SHUTTLE TOM AND JERRY RIGHT YELLOW

Taiche

(╯°□°）╯︵ ┻━┻

___alt a écrit :

Monde de merde.
Want my holidays back.

Encaisse [:j'invoque taiche]

---------------
Everyone thinks of changing the world, but no one thinks of changing himself | It is the peculiar quality of a fool to perceive the faults of others and to forget his own | Early clumsiness is not a verdict, it’s an essential ingredient.

Jubijub

Parce que je le VD bien

SC2 c'est une drogue en fait

---------------
Jubi Photos : Flickr - 500px

el muchacho

Comfortably Numb

Sur son refus de la Légion d'Honneur octroyée à son insu à Jacques Bouveresse:

Citation :

Dans le cas des honneurs, je suis simplement trop sensible à ce qu'Alain appelle «le creux et le ridicule» de la chose pour réussir à la prendre au sérieux; et je trouve que les occasions d'être ridicule sont déjà bien assez nombreuses sans cela (je parle ici, évidemment, à titre strictement personnel). Je n'aurais donc sûrement pas accepté l'«honneur» dont nous parlons s'il était venu d'un gouvernement de gauche, mais je suis évidemment encore bien moins disposé à l'accepter d'un gouvernement comme celui dont nous subissons actuellement la politique. Si ceux qui sont à l'origine de la décision de me le conférer souhaitaient me manifester une forme d'égard pour ce que la lettre de la ministre appelle «un parcours professionnel exemplaire et des mérites éminents», la meilleure façon de le faire aurait certainement été de continuer à oublier, autant que possible, mon existence.

D'après ce que j'ai cru comprendre en lisant la presse, le gouvernement a su honorer comme il se doit ses amis à l'occasion de la promotion de la Légion d'honneur du 14 juillet et j'aurais préféré nettement ne pas me retrouver, à mon insu et contre ma volonté, dans la situation, peu agréable pour moi, de quelqu'un qui risque de donner l'impression de faire partie de ceux-ci ou en tout cas d'avoir accepté du pouvoir politique et de lui avoir même probablement demandé une chose dont on pense généralement, à tort ou à raison, qu'elle ne peut guère être obtenue que de cette façon.

Je sais naturellement très bien que les honneurs républicains, comme on les appelle, sont en principe conférés par la République, pour des services qu'elle juge dignes d'une reconnaissance spéciale, et non par un gouvernement particulier, quelle que soit la tendance politique de celui-ci. Mais ils sont malheureusement distribués la plupart du temps, dans les faits, d'une manière telle que l'on a plutôt tendance à se les représenter comme des faveurs que le deuxième octroie à ses amis et à ses protégés, ou en tout cas à des gens qui ont su se montrer suffisamment compréhensifs et même complaisants à son égard. Une conséquence fâcheuse qui résulte de cela est qu'en acceptant les honneurs, on risque fortement de se retrouver dans une compagnie assez peu honorable et même parfois peu fréquentable. Cela ne peut évidemment guère donner, dans la situation actuelle, à quelqu'un comme moi, qui n'a déjà intrinsèquement aucun désir de les obtenir, l'idée de les rechercher.

(...)
Je ne sais pas si ceux qui nous gouvernent, considèrent désormais, contrairement à ce que je croyais, pour ma part, naïvement être l'usage, comme normal d'ignorer l'avis de ceux qu'ils prétendent honorer contre leur gré et de les mettre purement et simplement devant le fait accompli. Si c'est le cas, cela ne constitue malheureusement qu'une preuve supplémentaire du mépris avec lequel ils sont capables de traiter des gens pour lesquels ils n'ont en réalité aucune estime réelle.
(...)
Quel regard le philosophe que vous êtes porte-t-il sur ce qu'on appelle désormais l'affaire Bettencourt-Woerth?

C'est une question qui demanderait des développements beaucoup trop longs pour que je puisse prétendre y répondre réellement ici. Ce qui est certain est que rarement un président de la République et son gouvernement ont fait savoir aussi clairement à la population que le problème principal, à leurs yeux, était de défendre les riches contre les pauvres, et certainement pas l'inverse. Quand on les écoute, on se dit que l'on devrait peut-être, tout compte fait, finir par éprouver de la compassion pour ces pauvres riches, qui ont tellement de difficultés et de problèmes: ils sont en permanence sous la menace d'une multitude de gens aigris et envieux qui rêvent de les dépouiller de leur argent et qui sont encouragés à cela par des intellectuels qui prêchent des formes d'égalitarisme puéril, rackettés par le fisc qui les prive d'une part beaucoup plus importante que partout ailleurs de ce qu'ils gagnent, à tel point que l'on devrait presque trouver normal qu'ils pratiquent la fuite à l'étranger ou l'évasion fiscale, etc. A force de penser et de proclamer que l'argent et, du même coup, ceux qui le détiennent ne bénéficient pas dans notre pays de la considération qu'ils méritent, on finit par en arriver à trouver normale une situation qui ne l'est pas du tout et qui est illustrée de façon exemplaire par ce qu'on appelle l'affaire Bettencourt-Woerth. Il est remarquable que, si quelqu'un se risque à parler à ce propos de «corruption», cela suscite, de la part des gens qui sont au pouvoir, une réaction d'indignation violente, tellement les élites politiques sont persuadées d'être a priori insoupçonnables, même quand elles entretiennent avec le monde de l'argent des relations de l'espèce la plus douteuse qui soit. Si ce que l'on peut craindre fortement se confirme (mais pour cela il faudrait évidemment que la justice ait la possibilité de faire réellement son travail), le mot «corruption» est pourtant bien celui qui convient pour décrire ce dont il s'agit.

Interview à Mediapart

---------------
Les aéroports où il fait bon attendre, voila un topic qu'il est bien

black_lord

Truth speaks from peacefulness

I WANT REDDIT BACK /FOU/

---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me

R3g

fonctionnaire certifié ITIL

el muchacho a écrit :

Un prog, ce qu'il faut bien comprendre entre la pratique du C++ et celle du Java, c'est qu'en Java, les IDE comme eclipse, IntelliJ ou Netbeans assistent énormément le programmeur quand il code. C'est véritablement de la direction assistée qui ajoute un plaisir certain à la pratique du langage.

Je ne sais pas si c'est maintenant le cas aussi pour le C++, mais en Java en tout cas, la gestion d'exceptions ne demande pas vraiment d'effort: quand l'éditeur voit qu'une méthode déclare une exception X, il propose automatiquement:
- soit d'entourer l'appel par un bloc try{...}catch(X){...}
- soit d'ajouter une clause catch(X){...} à un bloc try{...} existant
- soit d'ajouter une clause throws X à la signature de la méthode que l'on écrit.
Quand on écrit un new X(), l'éditeur propose d'ajouter automatiquement throws X à la signature (de toute façon on n'a pas le choix, sinon le compilo couine). Et bien sur il propose aussi d'ajouter une entrée pour décrire l'exception dans la Javadoc de la méthode.
C'est très confortable et ça oblige à traiter tous les cas. Il ne reste plus qu'à documenter les causes de ces exceptions, et bien sûr, c'est là que le code pêche le plus: la doc. Mais au moins, un codeur qui passe derrière sait que la méthode throws X et devra en tenir compte, soit en la chopant, soit en la laissant passer.

Du coup, en théorie, les specs d'exceptions sont lourdes à maintenir, mais en pratique, ce n'est pas mon impression. S'il y a du refactoring à faire (encore une fois entièrement automatisé par l'IDE, donc autrement plus confortable qu'en C++), c'est rarement au niveau des exceptions pour la bonne raison que les sources d'exceptions applicatives ne changent pas (absence de fichier, connexion foireuse, etc), mais plutôt du renommage ou l'ajout ou la suppression d'un argument à une méthode.

Je ne pense pas qu'on puisse se fier aux dévs pour documenter toutes les API qu'ils développent. De mon souvenir, en C++, dans une appli où les devs n'étaient pas très rigoureux, on pouvait se retrouver avec des exceptions qui pétaient au plus haut niveau sans qu'on ne soit plus capable d'en déterminer la provenance exacte. Tout ça parce que le développeur avait plus ou moins caché l'exception sous le tapis et/ou qu'aucune couche intermédiaire ne la traitait. C'est je pense un peu l'équivalent de ne pas traiter tous les codes d'erreur en retour d'une fonction C. C'est ce type de situation qu'on évite assez facilement en Java. Le fait que les exceptions Java, même wrappées, conservent toute la Stacktrace depuis leur origine est en outre une bouée de sauvetage vitale pour les exceptions runtime, notamment.

Voila, je ne suis p-ê pas très convaincant, mais je me base sur mes propres expériences des deux langages. Après l'expérience d'autres personnes peut être différente.

Comment reconnaître un paté, leçon 1 : safari prend ce post pour un article et me propose l'option reader pour l'afficher

Message cité 1 fois

---------------
Au royaume des sourds, les borgnes sont sourds.