Christophe Le Bot

  • Navigation rapide
Pratique de la conception numérique

Derniers commentaires

  • Test d’interface : paiement d’amendes en ligne
    • Rovellotti Olivier | Ce site est un véritable cauchemar UX Excellent article http://www.natural-solutions.e u/
    • Julien | Pour info, mon e-numero etait sur le cote gauche, ecrit verticalement, sans aucun label.
  • Agence web ou SSII : que choisir ?
    • Rovellotti Olivier | La limite n’est plus aussi claire qu’avant effectivement et les différence de prix sont du l’ordre du *10. Généralement les équipes dans les agences sont plus...
  • Une excellente thèse sur Simile Exhibit
    • Olivier Rossel | Bonjour. Malgre les annees, avez vous toujours en memoire vos usages d’Exhibit? Je serais ravi d’en discuter avec vous. Cordialement, Olivier Rossel.
  • Utiliser le planificateur de tâches OVH (crontab) avec PHP
    • Max | Bonjour, comme faire pour appeler une version de PHP qui n’est plus proposée par défaut dans le manager ? J’essaie de lancer un cron avec php 5.3 mais le log affiche No such file...
 

Archives
février 2008

Du bon usage des exceptions

Si nous intégrons tous la gestion des exceptions dans notre code source (enfin, je l’espère…), en faisons-nous vraiment bon usage ? Entre les « maniaco-dépressifs » qui en mettent partout et les « bricolo-codeurs » qui savent à peine les mettre en place, il y a un compromis… qui n’est pas toujours évident à trouver.

Erreur, dysfonctionnement et exception

Par définition, une exception n’est levée qu’en cas d’état exceptionnel de l’application. Le tout est d’arriver à définir l’état d’exception. Est-ce un dysfonctionnement applicatif grave (connexion à une base de données qui tombe, fichier applicatif introuvable, allocation mémoire excessive, objet corrompu) ? Est-ce un fonctionnement normal mais exceptionnel (erreur d’authentification utilisateur, données entrantes non conformes) ? Est-ce une situation fréquente mais ne répondant pas au scénario optimal d’utilisation (mauvaise utilisation de l’application, erreurs de saisie d’un utilisateur) ?

Après avoir vu tous les cas sur le terrain, mais aussi dans des documents de référence, j’avoue ne plus savoir où placer le curseur…

Réserver l’exception aux dysfonctionnements

Pour ma part, je préfère garder l’exception pour les situations les plus rares et les plus graves, ce que je définis comme des situations exceptionnelles. Elles sont généralement dues à des dysfonctionnements de l’application, c’est-à-dire des états qui n’ont pas été prévus dans les séquences d’utilisation.

Sur ce principe, une erreur de saisie d’un utilisateur ne devrait jamais déclencher une exception lorsque sa valeur est contrôlée par l’application. Si j’entre une adresse e-mail invalide dans un formulaire, l’application traitera l’événement comme une erreur utilisateur et non comme un dysfonctionnement interne. Elle retournera le formulaire avec un joli message d’erreur… qui n’a rien d’exceptionnel puisque ce traitement fait partie du fonctionnement normal de l’application (mais pas de sa séquence nominal !). Même si cela semble évident (pour moi, du moins…), l’utilisation des exceptions pour ces cas est loin d’être anecdotique.

Bien sûr, si après validation de l’adresse e-mail l’application ne peut pas traiter normalement le formulaire, l’utilisation des exceptions permettra de trouver l’origine du dysfonctionnement, sans mettre les données dans un état inconsistant.

Trouver le bon équilibre

Dans le cas d’applications complexes où la modularité de code est de rigueur (genre « full MVC avec intégration de tous les designs patterns du GoF » !), savoir instancier puis récupérer une exception au meilleur endroit (ou moment pour les aficionados de la programmation événementiel) est déjà moins évident. Quels rôles jouent les différents niveaux de la partie M (modèle) ? Comment réagit la partie C (contrôleur) ? Comment gérer efficacement l’imbrication des exceptions (du noyau à l’interface en passant par les couches métiers) sans perturber la compréhension du problème par l’utilisateur ? Bien sûr, chaque cas est particulier, mais j’avoue que je souhaiterais bien discuter du sujet, autour de vos expériences.

Je vous passe la main !

Magento dévoile son business model

Varien, éditeur de la solution e-commerce open source Magento, vient de publier son programme de partenariat et, par la même occasion, offre un peu de visibilité sur son business model.

Très attendu après une campagne de communication parfaitement menée, Magento a pour ambition de devenir la référence des plates-formes e-commerce, grâce à un noyau robuste, une palette fonctionnelle riche et un « eco-système » basé sur une communauté d’intégrateurs. Si la version livrée en standard reste simple à installer, à paramétrer et à utiliser (une petite heure suffit pour avoir un site e-commerce fonctionnel !), sa faculté de personnalisation et d’évolution la rend sans équivalent sur le marché des solutions e-commerce open source.

Cependant, sortir du « standard Magento » réclamera des compétences pointues. C’est pourquoi, Varien cherche à développer un réseau de partenaires certifiés, sur un modèle proche de celui d’eZ Systems. Bénéfices pour Varien : une excellente visibilité, un retour d’expérience qui stabilise la solution, une communauté qui développe des extensions, des ventes de prestations en tout genre (formation, certification, documentation, support…). Bénéfices pour les partenaires : être référencés comme experts Magento, être en relation direct avec l’équipe de développement, bénéficier du marketing et des supports de communication réalisés par Magento, proposer des prestations de services aux clients, intégrer une solution robuste, fiable et évolutive.

Reste à savoir si Magento tiendra ses promesses. Mais, pour avoir soulevé le capot et réalisé quelques tests, j’en suis déjà convaincu ! Varien mène le développement en respectant les bonnes pratiques de l’édition d’applications. La solution repose sur Zend Framework (voir Zend Framework dans les starting-blocks) et utilise toutes les subtilités de la programmation orientée objet. Le code source est une succession de cas d’école.

Du sacré bon boulot, en somme. Tant du côté technique que du côté marketing…