Re: Une autre vision des exceptions

Après, vu l'état du code, c'est déjà un cauchemar à lire, sans la gestion des erreurs.

Pourquoi? Parce que ce genre de code spaghetti n'a pas été pensé comme il le faut.
D'ailleurs, exception ou pas, tu as une boucle infinie dans ton code (si getc() > 2 ou al).

Si c'est un parseur que tu veux, tu ne fais pas "en série", sauf cas très simple, mais "en parallèle" avec une gestion d'état. Et là, magie, le code devient beaucoup plus simple à écrire et parser, exceptions ou pas.

State get(State s) 
{
 int c = getc();
 if (c == EOF) return EOF;
 // Logique du parseur ici
 switch(s) 
 {
 case Start: /* Transition de start à XXX */ 
 if (c == 1) return ActionA; 
 else if (c == 2) return NeedMoreInput; 
 return ActionD;
 case NeedMoreInput: /* Transition de start à ActionB ou C */
 if (c==0) return ActionB; 
 return ActionC;
 default: return EOF;
 }
}
void parse() {
 enum State s = Start;
 while (true) {
 s = get(s);
 // Action du parseur ici
 switch(s) {
 case ActionA : actionA(); break;
 case ActionB : actionB(); break;
 case ActionC : actionC(); break;
 case ActionD : actionD(); break;
 case EOF : return;
 }
 } 
}

Utiliser des exceptions pour faire du retour de fonction, c'est créer 2 chemins (ou plus), là où il n'y en avait qu'un avant. Tu fais ça sur 10 niveaux, tu as maintenant 1024 chemins (ou plus) à tester et valider (donc 10x plus de code de test à écrire). Je te souhaite bien du courage.

Après, si une exception ne fuite pas vers le haut (difficile en général à réaliser), alors oui, les exceptions peuvent être utiles pour simplifier le code, mais il n'y a, dans ce cas, quasiment jamais d'avantage par rapport à des retours normaux bien gérés.
Par contre, avec l'aide de macro simples (remplaçant le try), tu peux capturer un callstack et là oui, c'est super bien pour retrouver le problème et simplifie fortement le code de log (uniquement à destination d'un développeur, car pour le pékin moyen, le log c'est mieux).