Reprise du message précédent :

Train à 00h51 à Bordeaux  

 
kitetoa

un petit lurkeur  

http://www.numerama.com/magazine/1 [...] ation.html

On savait déjà que ce serait n'importe quoi leur truc, mais là c'est pire que tout : t'installes le truc sur un vieux PC qui traine à la maison, tu l'allumes une heure ou deux dans la semaine, et tu peux télécharger tout ce que tu veux depuis ton autre PC et fournir une preuve de ta "bonne foi" à l'hadopi

et ça m'étonnerait pas que consultation-sfh@hadopi.net se fasse méchamment spammer...

kikoooooo

Ou Paracode

=> donc les checked exceptions ne servent a rien, non ?

Elle devrait arriver chez nous aussi
... dans un an ou 2

1 point Bon usage de smiley

Oui ?

tu vas demander un othographe a harko ? ou faire la sortie des bars pour essayer de voir gfive dans son état naturel ?

 
j'ai pas dis ça... ...sur les exceptions
 
 
admettons que tu utilises une API qui crache une chiée de checked exceptions :  
 
- au sein de ton code, tu catches celles qui t'intéressent, et tu laisses "remonter" les autres (si une exception n'est pas catchée, elle se propage à la méthode appellante, et ainsi de suite jusqu'à péter dans main() si tu fais rien)
- tu mets juste avant le main un catchAll (autrement dit, tu fais qu'une des premières méthodes juste sous ton main ou équivalent catch Exception, de sorte que tu as un traitement par défaut pour les checked exception que tu ne veux pas te faire chier à traiter manuellement
 
 
je trouve ça plutot flexible moi
après c'est certain, rien ne t'empeche de faire ça avec des exceptions unchecked, mais disons que le système t'oblige à mettre un framework minimaliste de gestion des exceptions en place
 
vu qu'il se contourne en rajoutant un try / catch au bon endroit, je vois pas l'intéret d'hurler à la mort contre ce truc

Tu comptais pas appeler tes gamins Tyberius et Lathrop ?

Ah non mais tant qu'on étant dans les prénoms pas courants, je voulais apporter ma contribution

Les checked exception, je voyais ça comme un officier de la gestapo qui te balance une groosse lumière dans la gueule et te hurle "NOUS AFFONS LES MOYENS DE FOUS FAIRE CATCHER ZETTE EGZEPTIONNE !". J'imaginais qu'elle devais être catchée Par la méthode appelante, pas qu'elle pouvait remonter jusqu'au main.
Je suis déçu qu'on puisse contourner l'obligation de catcher l'exception aussi facilement  

Tant que c'est sur le PC. Le jour où les opérateurs se mettent à collaborer pour installer le mouchard sur la box, on l'a dans le cul. Espérons que Xavier Niel leur fasse un gros doigt d'honneur.

Voila.

RuntimeException si je ne m'abuse. Celles-ci, on n'est pas obligé de les déclarer, et en pratique on ne le fait jamais.
C'est une distinction pas idiote, dans la mesure où c'est la distinction entre erreur applicative (FileNotFoundException ou XMLSyntaxException par ex) et erreur de codage pur (division par zéro, NullPointerException par ex), qui en C++ donneraient de toute façon lieu à un crash direct. On peut catcher toutes les exceptions si on veut, mais le compilateur ne force de catcher que les exceptions de type applicatif, les secondes devant passer pour être détectées le plus tôt possible, c-à-d en phase de test. Sauf p-ê dans une fusée, un recover sur un NullPointerException (NPE) n'a de toute façon pas vraiment de sens dans la mesure où le code qui suit va déconner gravement (on assume que l'objet sur lequel on agit existe), et au final, on s'éloignera de la cause, ce qui rendra le débogage bcp plus difficile.

Pour le point 4, c'est vrai que c'est assez chaud dans le cas général, mais je pense que si on réfléchit utilisations pratiques, les exceptions ne se prêtent qu'à des cas particuliers (des conditions exceptionnelles) justement, où les templates ne sont pas trop concernés. Si tu as des contre-exemples pratiques en tête, je veux bien que tu m'en cites.

En java >1.5 (je tiens à dire que je n'ai qu'une faible pratique de java >= 1.5), on arrive à faire cohabiter exceptions et Generics (plus ou moins l'équivalent des templates) en spécialisant les templates pour certains types de classes qui ne dérivent que d'une classe donnée que le template sait gérer.

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. Ca fait des traces d'exceptions relativement moches et redondantes (je te rassure: moins qu'une trace du compilo C++ quand il pète sur un template), mais c'est pratique dans la mesure où en prod, quand N applis communiquent et que l'une d'elles se met à chier, on arrive à voir assez facilement dans les traces qui est concerné.
Evidemment, si dans une couche intermédiaire, un codeur oublie de wrapper l'exception d'origine, elle est perdue et on est cuit pour le débogage, mais c'est facile d'obliger à l'inclure en exposant des constructeurs adaptés.

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.

Voila, Exception.

http://www.javapractices.com/topic [...] .do?Id=129

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".

Ouais ça va être plus chaud. Mais si on prend l'exemple de bitorrent, il suffit de faire passer les connexions vers le tracker et les peers en ssl et la box n'y voit que du feu, non ?

Non, ça n'est pas une bonne pratique dans le cas général pour les raisons expliqués plus haut.
Le cas le plus courant où on fait du "catch all", c'est lors d'appels de libs natives (JNI) où on sait pas trop à l'avance ce qui va te pêter à la gueule, auquel cas on chope l'exeption et on met "L'appel de telle lib native a foiré pour une raison inconnue".

 
je vois mal un mec qui a bossé dans le porno et possède quelques bars à hotesses dans paris collaborer comme ça

Si tout le monde passe en SSL, ça devrait aller, oui, parce que là, ce sont les ayant droits qui ne pourront pas prouver que ce qu'on échange est illégal. Et le gouvernement l'aura doublement dans l'os, sachant que les RG ne seront pas, mais alors pas contents du tout.
Mais ça limite essentiellement les échanges à la France, vu que la plupart des peers étrangers ne sont pas en SSL, - et à iPredator -. La seule riposte gouvernementale serait alors d'interdire toute forme d'encryptage "pour raisons de sécurité nationale" , ce qui soulèverait des problèmes d'atteinte aux libertés suffisamment importants pour être posés au niveau européen. (sans parler de la défnition même d'encryptage, qui ne va pas être facile à choisir pour un texte de loi)

Sachant au final que toute cette mascarade indigne de descendants de 1789 provient d'un petit groupe d'intérêts privés qui fument des cigares à la SACEM.

Si on met un petit routeur Linksys devant la box mouchardée pour détourner les trames sur le second PC, ça devrait marcher, non ?
 
Sinon, en interceptant les appels au fichier journal encrypter, il y a moyen de modifier les données à encrypter en "tout va bien" , et Gesthadopi.
Je pense que ça devrait arriver dans les 2 semaines suivant la mise en circulation du mouchard.

Y'a des gens qui piratent encore ?

 
Jusqu'à nouvel ordre tu peux avoir l'adsl sans box, par exemple chez Orange suffit de pas prendre la livebox et d'acheter un router  

 
dans le NPDC, sans doutes, ouais

Oui mais ça c'est pas suffisant pour contrer l'Hadopi. A partir du moment où on a été repéré par les ayant droits, il faut impérativement avoir eu le moyen de journaliser ses téléchargements comme exigé par Hadopi, car c'est considéré comme la seule preuve valide avec cette loi pour prouver son innocence. Avec cette loi de merde, la charge de la preuve est inversée, il faut prouver son innocence. D'où le terme bien orwellien de "sécurisation": si on n'installe pas le mouchard, on est menacé à tout moment de poursuites.

 
donc en tant que barbu faut que j'achète moi-même l'OS permettant d'installer le mouchard gouvernemental  

Même les gens qui ne téléchargent pas sont susceptibles d'être emmerdés si ils ne sécurisent pas leur liaison Wifi par exemple. C'est intéressant pour le cas des hotels, au passage. Un tel système interdit le wifi dans les hotels et dans tous les lieux proposant le wifi au public en général.
 
Un cas réel de retour en arrière.

Putain mais les vieilles qui braillent tous les matins dans ma rue, tuez les
Là y en a une à 50m de chez moi, sur son seuil de porte qui parle à toutes ses copines vieilles qui passent, et maintenant qui discute hurle avec un type depuis 10min, je peux entendre tout ce qu'elle dit

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.

 
ok  

 
Ce serait la fin de nos libertés

Facebook_directory_-_personal_details_for_100_million_users.5722635.TPB.torrent
http://it.slashdot.org/story/10/07 [...] rrent-Site

Si on met un routeur DEVANT la box, je me demande si on ne peut pas simplement court-circuiter le système.

Parce que patcher la box elle-même c'est possible mais un peu chiant. La faille serait alors de repérer le code de journalisation et de modifier les données avant qu'elles soient encryptées. Mais en plus, il faudrait empêcher toute mise à jour logicielle de la box, parce qu'une fois la triche connue, le FAI n'aurait qu'à faire cette maj logicielle et tout serait à refaire.

Mais si c'est mis en place, on sera effectivement à peu près au niveau de la Chine pour ce qui est de l'accès à internet, et on pourra ajouter le terme "surveillée" à "Liberté, Egalité, Fraternité".

J'te suis pas, là.
La box fait modem ADSL et routeur à la fois, tu peux pas intercaler un routeur à toi entre les deux

Ah merde, c'est vrai.

Donc il faudra patcher la box et empêcher toute mise à jour en ligne. Je subodore que la FAI qui laisse cette possibilité, ou qui décide de ne pas moucharder a box, va voir le nombre de ses clients exploser.

 
 so? du webcrawling sur les pages en open access, normal

http://www.flickr.com/photos/amonroy/4842331295/
 
Je me demande si ce couillon a envoyé une lettre à Google quand ils ont mis le jeu en javascript en ligne sur leur front page.

 
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.
 

 
La détection d'une erreur de codage doit entraîner l'arrêt du programme le
plus rapidement possible et avec le minimum d'effets permanents.
Utiliser un mécanisme partagé avec des erreurs applicatives a trop de
risques d'effets permanents indésirables; c'était un de mes rares reproches
à Ada quand j'en faisais (avant même de faire du C++, il y a des points ou
mon opinion sur Ada a changé, pas celui-là).
 
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.
 

 
Je garde parce que je crois que c'est un argument suffisant pour expliquer
l'absence en C++ d'une vérification statique et qui empèchera toujours son
introduction.
 

 
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.
 
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.
 

 
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.
 

 
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)
 

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

 
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.
 

Exactement. Moi ce qui m'horripile c'ets les gens qui throw sur une violation de precondition.

Le texte des messages ne fait plus toute la largeur du conteneur mais seulement la moitié

Ca te permet d'éviter de stalker les profiles des bonnasses 1 par 1

s'ils commercialisent ce concept il y en a qui vont pas y faire pousser que des salades
http://www.paperblog.fr/3475436/le [...] n-hyundai/

 
Faudra enlever des étages alors parce que une plante de canna c'est plus haut que ça

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