Les exceptions Java

Les exceptions en Java constituent un mécanisme puissant de traitement des erreurs aussi bien dans une phase d’exécution normale de l’application que dans les phases de débogage. J’aime comparer Java et Pascal ou C. Dans le premier, tout événement anormal (utilisation d’un pointeur null ou un problème d’entrée/sortie par exemple) doit provoquer un arrêt du flot d’exécution… immédiatement ! Alors que dans le second, il peut se passer de nombreuses instructions entre l’origine d’un problème et sa manifestation, rendant le débogage plus difficile.

La perception des exceptions par le programmeur est malheureusement souvent mauvaise. Le programmeur ressent la gestion des exceptions comme une contrainte et s’en débarrasse en la masquant ou en la laissant remonter, par paresse. Cela entraîne un mauvais usage des exception et c’est bien la mauvaise gestion des exceptions en Java par le programmeur qui font dire à certain que java ne sait pas gérer les exceptions.

Pourtant il suffit de respecter quelques principes simples pour tirer le plus grand bénéfice de ce mécanisme de gestion d’erreur.

Une exception doit être rattrapée si on sait comment la traiter

Par traitement on entend une action spécialement prévue dans le cas de l’exception. Par exemple une IOException pourrait être traitée en réessayant un certain nombre de fois ou en demandant à l’utilisateur de changer un paramètre (chemin de fichier par exemple). Mais attention, rattraper une exception ne suffit pas à la traiter correctement. Il ne suffit pas d’encadrer une un appel pouvant lever une exception avec un try catch pour s’assurer d’une bonne gestion. En effet, considérons le code suivant:

instruction1();  // lève une exception
instruction2()

Il ne suffit pas de faire:

try {
  instruction1();
}
catch (Exception e){
  // on gère l'exception
}
instruction2();

Le code précédent assume que la gestion de l’exception doit permettre l’exécution de instruction2(), mais est-ce que la gestion de l’exception le fait réellement ? un simple log sera bien sûr insuffisante, ne vaudrait-il pas mieux ne pas exécuter instruction2() ? Ou bien mettre la 2e instruction dans le bloc try également ? La réponse dépasse le cadre de la gestion des exceptions pour entrer dans celui de la robustesse du code.

Si on ne sait pas comment réagir face à l’exception la solution la plus simple est de ne pas la rattraper.

Sinon on ne rattrape pas et on la déclare

Déclarer l’exception signifie que la méthode doit la porter dans sa signature. C’est le point le plus important. Déclarer l’exception permet de la remonter correctement. Le code appelant qui peut être la méthode main() devra alors gérer l’exception, ce qui nous garantit un traitement correcte de l’exception: au moins par un arrêt du flot d’exécution.

Trop d’exceptions à déclarer: on encapsule

Les programmeurs non habitués à la gestion des exceptions seront alors gênés de devoir déclarer de nombreuses exceptions en signature de méthode.  Il faut alors prévoir une hiérarchie d’exception applicative plus simples qui va permettre d’encapsuler des exceptions plus techniques afin de limiter le nombre d’exception à déclarer dans les méthodes. Le programme va alors devoir rattraper les exceptions (technique ou de base) afin de les encapsuler dans des exceptions applicatives.

Cas des conteneurs d’application

Arrêter le flot d’exécution voire même la JVM est possible quand le programme est seul au monde. Dans le cas d’application web ou de conteneur d’EJB, le code ne doit pas arrêter la JVM car il s’inscrit dans un serveur d’application: il n’est pas seul au monde. Les conteneurs (tel que tomcat) sont bien écrits et une application ne peut pas arrêter la JVM à cause d’une exception qui remonterait toute le pile d’appel. Il y aura un appel qui va rattraper l’exception et en faire quelque chose comme par exemple l’écrire sur la sortie de la JSP. Cela est souvent vu comme une mauvaise chose pour l’utilisateur mais doit être vue comme une bénédiction par le programmeur. C’est la solution minimale qui assure un débogage de l’application.

Empiler ou découpler ?

Un reproche fait aux piles d’exception de Java c’est sa verbosité. C’est un reproche qui peu s’entendre. En effet prenons le cas d’une application multi-tiers où une erreur d’accès à la base de donnée remonte jusqu’à la couche de présentation sous forme d’une pile d’appel qui dévoile toutes les couches de l’application: action de l’utilisateur, appel de service, appel à la couche de persistance et finalement une belle erreur JDBC avec un code obscure en provenance du SGBD. Vous connaissez ce scénario  ? Il arrive quand on laisse filer l’exception ou que l’on encapsule en faisant référence à l’exception original via un appel à :

public Exception(Throwable cause)

Cette façon de faire permet de conserver l’exception d’origine et ainsi de ne pas perdre la pile d’exécution au moment de la levé de l’exception d’origine. C’est la façon de faire la plus sûr et la plus simple. c’est de l’empilage d’exception. Si on ne souhaite pas remonter dans les couches supérieures (appelantes) la pile d’exécution car on considère que cela n’est pas de leur ressort, on peut découpler i.e simplement lever une exception à destination des couches supérieures sans passer l’exception qui en est la cause mais alors il faut tracer (loguer) la cause de manière complète i.e. loguer la pile d’exécution. Ainsi on résout de manière élégante le problème des piles d’erreurs trop verbeuses dans la log des couches supérieurs tout en gardant dans les log des couches inférieurs la trace complète des exceptions à des fin de debug. Cette technique sera particulièrement efficace quand on choisit de mettre en œuvre des log par couche d’abstraction: une log pour la couche de présentation, une log pour la couche métier et une log pour la couche de persistance… ce qui nous amène à l’épineux problème de la gestion des log et c’est une autre histoire.

 

Publié dans Langage | Marqué avec | Laisser un commentaire

Analyse dump mémoire JVM sur AIX (ibm)

La JVM d’IBM sur AIX produit un dump mémoire au format non standard. La JVM de Sun (pardon Oracle….) crée un fichier HPROF tandis que la JVM d’IBM crée un fichier PHD (Portable Heap Dump). C’est un peu déconcertant car JVisualVM ne sait pas lire le PHD. La solution est alors d’utiliser Eclipse MAT dont l’ascendance génétique n’est pas étrangère à IBM.

Après avoir téléchargé la dernière version de MAT sur le site http://www.eclipse.org/mat/ il faudra tout de même encore ajouter une extension pour qu’il puisse lire les PHD. Dans le menu « install new Software » on devra ajouter le site

http://public.dhe.ibm.com/software/websphere/runtimes/tools/dtfj/

On peut également ajouter MAT (Memory Analyzer Tool) en temps que plugin dans un Eclipse standard. Pour cela il faudra ajouter le site suivant dans le menu « install new software »:

http://download.eclipse.org/mat/1.4/update-site/

Ensuite pour pouvoir ouvrir des dump de JVM ibm il faut ajouter l’extension vue en premier.

Publié dans Application | Marqué avec , , , | Laisser un commentaire

Passons à TLS

Bien que SSL soit supplanté par son successeur TLS, il reste quand même encore utilisable car bien des serveurs le garde comme protocole au cas où un client ne supporterait pas TLS. L’enfer est pavé de bonnes intentions…. si SSLv2 est aujourd’hui considéré comme défaillant, ce n’est pas le cas de SSLv3 qui reste encore dans les bonnes grâces de la configuration de apache2 sous Debian 7. En effet dans le fichier /etc/apache2/mods-enabled/ssl.conf on trouve:

SSLProtocol all -SSLv2

Ce qui indique l’utilisation possible de  TLS et de SSLv3. Malheureusement une information parue sur le site américain NVD qui recense les vulnérabilités des logiciels, SSL est intrinsèquement vulnérable (y compris SSLv3) à l’attaque de l’homme du milieu. Cela veut dire qu’il faut absolument ne plus utiliser SSL mais son successeur TLS.

La mise en place du banissement de SSL dans nos serveurs web consiste à le supprimer de la liste des protocoles utilisables par apache. Dans le fichier ssl.conf il suffit de mettre:

SSLProtocol all -SSLv2 -SSLv3

On pourra également en profiter pour hausser si n’est déjà fait le niveau de cryptage (algorithmes utilisés) que le serveur accepte de faire. Le monde libre (et donc gratuit) ne laisse aucune excuse au client qui n’utilise pas un logiciel récent et supportant les algorithmes de chiffrement les plus sûrs. Toujours dans le fichier ssl.conf il suffit de mettre:

SSLCipherSuite HIGH:!ADH:!MD5
Publié dans Actualité, Application, Paramétrage | Marqué avec , , | Laisser un commentaire

Chainsaw sous Debian 7

Debian 7 Wheezy propose open-jdk 6 comme JVM par défaut. Malheureusement cela pose un problème avec la fenêtre de popup au démarrage de Chainsaw qui propose d’ajouter un récepteur de log. Cette fenêtre reste vide sans aucun moyen de la fermer. Un open-jdk 7 ne change rien  à l’affaire et il faudra ce résoudre à utiliser la JVM Oracle.

Publié dans Application | Marqué avec , , , | Laisser un commentaire

Eclipse Luna sous Debian 7 ne démarre pas

En train de tester en parallèle les IDE Netbeans et Eclipse sous Debian 7 Wheezy, on constate rapidement que les versions dans le dépôt ne sont pas les plus récentes. En effet Debian 7 est livré avec java 6. Netbeans et Eclipse sont respectivement disponibles en version 7 et 3.8.

Un petit passage par le gestionnaire de paquet aptitude permet de récupérer java 7 en version openjdk comme la 6 installée par défaut. D’autres jvm sont présentes, il suffit d’aller voir en faisant:

ls -l /usr/lib/jvm

Afin de bénéficier de java 8 il faudra télécharger la JVM chez Oracle. On pourra installer les JDK Oracles n’importe où et ajouter des liens symboliques dans le répertoire /usr/lib/jvm

La dernière version de Netbeans, 8.0.1 est obtenu sous la forme d’un installeur sh qui trouve immédiatement le dernier JDK (sans doute en scannant le répertoire cité précédemment). L’installation du dernier Eclipse, nom de code Luna, version 4.4.1 est un peu plus brute: c’est une simple archive.

Arrive le moment du lancement: Netbeans démarre sans souci, à l’aide du raccourci ajouté sur le bureau. Malheureusement je ne peux pas en dire autant d’Eclipse qui plante au bout d’une dizaine de seconde sur le « splash screen ».  La JVM par défaut sous Debian 7 est l’open-jdk 6, j’ai eu donc l’idée de tester Eclipse avec les autres JVM disponibles sous mon système: java 6 en version oracle, java 7 en open-jdk, en oracle, java 8 de oracle. Pour cela il faut utiliser le fichier eclipse.ini en ajoutant l’option -vm comme par exemple

-vm
/usr/lib/jvm/jdk1.8.0/bin/java

Rien à faire, Eclipse plante toujours. La pile d’erreur indique un problème avec GTK et finalement c’est le prix à payer quand on ne fait pas du pure Java. Ah ! Eclipse que tous les développeurs ont adoptés parce que SWT, le boîte à outils graphique, faisait du natif là où Swing écrit les widget avec du code Java donc plus lent. Voilà ce qui arrive quand on vend son âme au diable, fini le WORA. C’est un comble pour un développeur Java de devoir modifier son IDE pour lui dire d’utiliser GTK2, solution pour faire fonctionner Eclipse sous Debian 7. Dans le fichier eclipse.ini il faut mettre juste après l’option startup :

--launcher.GTK_version
2

 

Publié dans Application | Marqué avec , , , | Laisser un commentaire

Exploitabilité des log

Les mécanismes de log en Java, tel que log4J, sont bien matures et font partie de l’état de l’art des développement informatiques. Les développeurs ont l’habitude de s’en servir en vue de mettre au point les programmes et de corriger les bugs après avoir pu les reproduire en local. En production, les log sont généralement moins verbeuses et ont pour objectif de ne signaler que les problèmes sérieux  qui nécessitent un action de l’exploitant voire une remontés rapide aux équipes de développement pour fourniture d’une correction.

Un aspect de la gestion des log est néanmoins peu adressé. Il s’agit de l’exploitabilité des log quand il s’agit de connaître le comportement de l’application en production. La production, environnement sécurisé n’est pas accessible aux développeurs qui doivent souvent demander les log à l’exploitant de production voire ensuite demander d’augmenter le niveau de log en production pour cibler le problème.

De plus, dans le contexte actuel, d’applications communiquantes, où une fonction est assurée par la collaboration de plusieurs applications, la compréhension des problêmes en production passent par une vue globale des log. La log du logiciel est multi-applicative.

Nous prenons comme exemple l’API de log Lg4J devenu le standard defacto de la log en java avant que Sun n’ajoute un mécanisme de log dans le JDK même. Quels sont les outils à la disposition ? Log4j, Chainsaw et Flume méritent-ils que l’on s’y intéressent de plus près ?

Publié dans Application | Marqué avec , | Laisser un commentaire

Vive la ligne de commande pour lire les vidéos sur internet

L’essor de la vidéo en streaming est une cause d’engorgement du réseau. La mauvaise solution apportée par les opérateurs d’internet est d’instaurer un péage: qui peut payer pourra voir son traffic vidéo privilégié. Cela est à combattre car allant à l’encontre de la libre circulation des données: internet doit rester agnostique du contenu des paquets qui transitent. Cette libre circulation permet à n’importe qui d’avoir l’audience qu’il merite puisque plus son contenu est intéressant, plus il pourra être consulté sans préjuger de sa capacité financière.

L’engordement du réseau à cause de la vidéo reste néanmoins un problème entier et comme souvent nous avons des oeillères qui nous empêchent de voir la solution. Dans de nombreux cas, le streaming n’est pas une contrainte: le poste client est-il réellement limité en espace de stockage ? Le téléchargement de la vidéo est alors un mode de visualisation qui répond au besoin et évite l’engorgement du réseau en cas de visionnage répété de la même vidéo… Il existe des plugins pour Firefox afin de télécharger les vidéos des sites qui les proposent en streaming pour mieux garder l’utilisateur captif de leur portail. Hier soir pourtant ces plugin montrèrent une faille: impossible de télécharger la vidéo convoitée. Je n’en connais pas la cause mais en passant par le script youtube-dl la vidéo était sur mon disque dur en deux temps trois mouvements via la petite commande suivante:

youtube-dl https://www.youtube.com/watch?v=v4yOa3tBrB8

Ce programme mérite à être connu car il permet de s’affranchir de la mise à jour forcée vers les nouvelles versions de flash et d’éviter de cautionner l’usage de javascript propriétaire dans nos navigateurs. La ligne de commande c’est bien !

Publié dans Application | Marqué avec , | Laisser un commentaire

Un webmail libre (français)

Je n’ai plus de compte gmail et c’est tant mieux ! Plus besoin de m’inquiéter de savoir si quelqu’un va lire mes courriels sur les serveurs de google. Même si on a rien à se repprocher, on n’a pas envie que quelqu’un lise le contenu de ses courriers, fusse ce quelqu’un un algorithme pour vous envoyer de la publicité ciblée.

Le remplacement de gmail par son propre service de messagerie est assez facile. Louer un nom de domaine, monter son serveur mail et un webmail associé sont en effet des tâches largement documentées ici et là. Que faire en cas de panne ou si on n’a vraiment pas la fibre technique pour monter son serveur mail ? Quel service de webmail respectueux des libertés peut-on utiliser ?

Il existe des solutions mettant en oeuvre des logiciels libres et pour ne rien gâter il y en a une Mailoo qui est basée en France. Quitte à se faire espionner par les services secrets, autant que celà soit par ceux de son propre pays. Mailoo est référencé par la FSF comme fournisseur de webmail libre, alternative libre des gmail, hotmail etc. L’espace de stockage est de 1Go, ce qui n’est pas mal à la vue de la gratuité du service.

Publié dans Application | Marqué avec | Laisser un commentaire

Gardons le contrôle sur nos machines et donc sur nos données | hidden.bressure.net

Qui contrôle votre ordinateur ? vous où bien l’éditeur des logiciels qui s’y trouvent ? Pour beaucoup d’utilisateurs, attirés par la facilité ou le bling-bling du matériel, ce sont bien les éditeurs des systèmes et  des applications non libres qui contrôlent les machines et les données de ces utilisateurs.

Pourtant des alternatives existent. Pour garder le contrôle sur nos machines il suffit de n’y installer que du logiciel libre. La grande quantité de logiciels disponibles dont les utilisateurs sont gardés à l’écart par les systèmes privateurs, donnent rapidement à celui-ci le contrôle sur son matériel et lui ouvre le champ des possibles. Aussi la messagerie ainsi que le mal nommé cloud sont des applications qui n’ont pas besoins d’être déportées chez un quelconque hébergeur. Nous devrions tous être nos propres hébergeurs de mail et de cloud.

La suite sur mon blog caché avec Tor:

Gardons le contrôle sur nos machines et donc sur nos données | hidden.bressure.net.

Publié dans Application | Marqué avec | Laisser un commentaire

Debian dans les heures sombres du libre | hidden.bressure.net

L’orateur, Stefano Zacchiroli, nous explique quelles sont les motivations qui lui ont fait adhérer au libre et pourquoi l’adoption du libre est selon lui à un tournant. En cause le cloud, contre lequel Stallman propose le rejet mais Zacchiroli préfère poser la question de la solution que peut apporter Debian (et les développeurs de distributions) pour offrir une solution libre au moins équivalente aux cloud privateurs de liberté.

 Debian_in_the_Dark_Ages_of_Free_Software

 

 

Billet posté initialement sur mon blog caché avec Tor:Debian dans les heures sombres du libre | hidden.bressure.net.

Publié dans Actualité | Marqué avec , | Laisser un commentaire