J’aimerais bien un article sur les Exceptions, ça pourrait le faire vu que c’est le truc qui me casse les couilles le plus souvent en Python ;)

Cela dit dans le groupe sidérurgique qui m’emploie, nous nous sommes séparés de l’off-shore en Inde. Les programmeurs ont un niveau moyen et surtout ils ne connaissant pas les règles métier.
Du coup les programmes nous sont renvoyés pour correction et les coûts explosent : on a donc stoppé notre collaboration et encore je ne vous parle pas des tentatives de passage de SI en full .net, on a dû faire machine arrière tellement ça tient pas la charge ;)

@Krysztof von Murphy: le prix de l’offshore, les gens ne le comprennent qu’une fois qu’ils n’ont plus d’argent pour payer quelqu’un qui connait son métier. C’est d’autant plus dur qu’il y a de très mauvais pros en France, et de très bon offshore, du coup l’évaluation par un commercial au dela du prix du devis, ben…

Par contre ton post me donne la raison pour laquelle j’avais parfois du mal à arrêter ce script, merci pour ça ^^

Un des problèmes de ne pas préciser du tout d’exception, c’est que du coup ça choppe aussi les SystemExit et KeyboardInterrupt. C’est à priori pas gênant pour un serveur, mais plus chiant pour une application desktop…
Une bonne pratique est de mettre au moins Exception.
http://docs.python.org/2/library/exceptions.html#exception-hierarchy

BEGIN
(logique complexe de mise à jour
de données de stock, financières...)
EXCEPTION
WHEN OTHERS THEN NULL ;
END ;
COMMIT ;

Toute erreur sera passée à la trappe, et la cohérence des données n’est pas garantie, pour ne pas dire qu’elle devient complètement aléatoire.

J’appelle ça du sabotage. J’ai vu ça dans les spécifiques de l’ERP d’une usine, dans du code qui revenait d’Inde (ben oui, c’était moins cher que les prestataires locaux embedded dans l’équipe client et qui ont facturé 6 mois de plus pour remettre d’équerre).