J’ai récemment dû traiter un bug qui m’a paru étrange de prime abord, et qui fut finalement simple à corriger.
Le contexte
Un programme qui propose un paramètre à l’écran de sélection ; ce paramètre peut recevoir soit un chemin de fichier, soit un nom complet de fichier.
À l’exécution, si aucun nom de fichier n’est donné, alors c’est le programme qui le génère, et l’ajoute au chemin, pour plus tard créer ledit fichier.
Le problème rencontré
En arrière-plan, le programme se comportait systématiquement comme si seul un chemin avait été fourni, quand bien même un nom de fichier complet avait été renseigné.
L’analyse
Cela fonctionnait bien en avant-plan.
Cela fonctionnait bien lors du debug du job depuis SM37 → JDBG.
En étudiant la façon de déterminer le cas (chemin seul ou nom complet), j’ai vu que c’était le module fonction SO_SPLIT_FILE_AND_PATH qui était utilisé pour découper la chaîne de caractères.
Ce module fonction se veut indépendant du système d’exploitation (pour rappel, sous Windows, les répertoires sont séparés par un anti-slash « \ » alors que sous Unix, c’est le slash « / » qui est utilisé). Pour faire cette distinction, des fonctions bas niveau liées au GUI sont utilisées, ceci permettant de déterminer le système d’exploitation côté client.
On l’aura compris, le problème se situait ici : en mode batch, par définition, il n’y pas de client.
La solution
Le module fonction susmentionné a été remplacé par le module fonction TRINT_SPLIT_FILE_AND_PATH qui fait globalement la même chose, mais indépendamment du système d’exploitation du client. C’est directement dans la chaîne de caractères qu’est distingué le cas Windows ou Unix, et en tout état de cause, cette information n’est pas nécessaire. Le but étant simplement d’extraire le nom du fichier de son chemin (grosso modo en découpant la chaîne selon l’un des séparateurs « / » ou « \ » et prendre la dernière partie en tant que nom, sauf si la chaîne d’origine termine par l’un de ces séparateurs).
Moralité
C’est souvent une bonne idée d’utiliser les modules fonctions du standard, mais il faut bien penser à regarder sous le capot pour s’assurer qu’ils répondent correctement au besoin adressé.
En outre, des tests bien effectués auraient pu permettre de détecter le souci bien avant que le programme soit livré en Production.