

BACKSIC
Code, Devlog, ActualitésNOK
Lundi 17 Novembre 2025
Jusqu'à présent le compilateur arrêtait d'analyser une ligne sitôt une erreur détectée... Parfaitement logique de ne pas essayer de compiler une ligne qui n'a pas de sens.
Mais c'était trop beau et trop simple pour être valable. Car invalider des lignes avait l'effet de créer de nouvelles erreurs fictives à l'autre bout du code :
La logique de validation des lignes a donc été revue de bout en bout pour pouvoir aller le plus loin possible dans la compilation : poursuivre coûte que coûte malgré toutes les horreurs qui pourront y être écrites.

J'ai un code spécial en stock dont toutes les lignes comportent une erreur différente. J'ai été obligé de créer l'erreur "CHAOS" quand vraiment c'est impossible de s'y retrouver. Mais ça devrait être un cas extrême... j'espère :)
Mais c'était trop beau et trop simple pour être valable. Car invalider des lignes avait l'effet de créer de nouvelles erreurs fictives à l'autre bout du code :
if ?a=1 orCas simple : une erreur sur une condition, c'était une condition non acceptée... donc une fin de condition incomprise. C'est le problème de vouloir trouver et indiquer le maximum d'erreurs. Trop ou pas assez...
print "ok"
end
La logique de validation des lignes a donc été revue de bout en bout pour pouvoir aller le plus loin possible dans la compilation : poursuivre coûte que coûte malgré toutes les horreurs qui pourront y être écrites.
Stress test
J'ai un code spécial en stock dont toutes les lignes comportent une erreur différente. J'ai été obligé de créer l'erreur "CHAOS" quand vraiment c'est impossible de s'y retrouver. Mais ça devrait être un cas extrême... j'espère :)

© 2026