Comment traiter les erreurs ?#

étant un processeur de macro (macroprocessor), ces messages d’erreur restent souvent difficiles à comprendre ; c’est une propriété (apparemment invariante) de ce type de programme. Knuth met en lumière le problème dans le book en suggérant que vous acquériez les compétences d’investigation d’un Sherlock Holmes des temps modernes pour traiter ces erreurs. Bien que cette approche présente un certain charme romantique, ce n’est pas une bonne solution pour un simple utilisateur de et Cette réponse (tirée en partie d’un article de Sebastian Rahtz dans le TUGboat volume 16, n°4, propose des lignes de conduite pour gérer les rapports d’erreur de et est suivie d’autres réponses sur les erreurs courantes (mais embarrassantes) que vous pourriez rencontrer. N’hésitez pas à vous référer à l”article, plus récent, de Barbara Beeton dans le TUGboat volume 38, n°2.

1.  Lire les erreurs#

Les messages d’erreur peuvent sembler énigmatiques à première vue mais ils contiennent souvent une indication sur la nature du problème. Voir la question sur la structure des erreurs pour plus de détails.

2.  Lire le fichier journal#

Le fichier .log contient souvent des indications sur des éléments que vous pourriez n’avoir pas compris, souvent des éléments qui ne sont pas présentés comme des messages d’erreur.

3.  Définir la quantité de contexte entourant les erreurs#

Les messages d’erreur vous donnent des extraits du code ou du document présents là où l’erreur « s’est produite ». Il est possible de contrôler la quantité de contexte que vous communique. De nos jours, dit à de vous restituer une ligne de contexte mais vous pouvez en décider autrement en indiquant dans le préambule de votre document :

\setcounter{errorcontextlines}{999}

Si vous n’êtes pas un programmeur très confiant, n’ayez pas peur de diminuer quelque peu le 999 : certaines erreurs vont générer beaucoup de texte et trouver alors les problèmes peut être un sacré défi.

4.  Utiliser les traces#

En dernier recours, l’utilisation de trace (tracing) peut être une technique très performante. Lire une trace intégrale de ou demande une sacrée constitution mais, une fois que vous savez le faire, la trace peut vous mener rapidement à la source d’un problème. Vous devez avoir lu une bonne part du book (voir Que lire sur et Plain ) pour bien comprendre une trace. v La commande \tracingall génère la version la plus exhaustive de la trace. Elle transfère aussi le document de sortie vers le terminal interactif, ce qui constitue, quelque part, un mélange pas très heureux (dans la mesure où la sortie générée est généralement vaste, toutes les traces à l’exception des plus simples demandent à être analysée dans un éditeur de texte séparément).

L’extension trace (distribuée pour la première fois avec la version de 2001 de ) fournit des mécaniques de trace plus pratiques. Sa commande \traceon vous restitue ce que fait la commande \tracingall en supprimant toutefois les parts de trace autour des zones particulières verbeuses de lui-même. Cette extension vous fournit également :

  • une commande \traceoff (il n’y a pas de commande « off » pour \tracingall) ;

  • et une option d’extension (logonly) vous permettant de supprimer le transfert de la sortie vers le terminal.

5.  Ne pas paniquer !#

Le meilleur conseil à donner aux personnes faisant face à des erreurs reste de ne pas paniquer : la plupart des erreurs sont évidentes lorsque vous retournez à la ligne de votre code source que vous indique Si cela ne marche pas, les autres réponses données dans cette FAQ traite de certaines des erreurs les plus bizarres que vous puissiez rencontrer. Vous ne devriez donc pas avoir besoin d’appeler à l aide du grand public mais, si c’est le cas, pensez bien à fournir un contexte complet (voir errorcontextlines ci-dessus) à vos interlocuteurs.

Sources

How to approach errors