@Pol63 : De ce que j'ai compris, lorsqu'il y a une First Chance Exception, certes cela se passe à bas niveau, mais "The point" c'est que le debugger va décider de quoi faire avec : L'ignorer et continuer, essayer de réparer tout seul ou lever une exception (ce qui est la pire des solutions. Quoiqu'il en soit ça prends du temps, c'est pour ça que par exemple il est plus rapide de tester une variable pour savoir si on divise par 0 plutôt que de laisser faire une division par zero encadrer par un try-Catch.
Cela n’empêche effectivement pas l'application de fonctionner mais je parle plutôt de propreté du code et de bonne pratique.
-> C'est pas faux. La méthode ne freine pas tant que ça le programme... Après question propreté, tout est une question de méthodologie. Si partout dans le programme on utilise les Throw pour stopper les procédures quand il y a une erreur, alors se serait plus propre de continuer ainsi qui serait propre. De mon point de vue, il y a d'autres manières de faire cela.
->L'avantage tout de même, c'est que dans n'importe quel procédure, il n'y a pas à prévoir des retours d'erreurs à chaque fois... avec des enums, des paramètres ou autre. Ce système permet à la fois de couper l’exécution et de remonter une info. 2 en 1.
Je pense qu'une exception doit rester quelque chose d'exceptionnel
-> Oui ! Mais là encore je pense que tu confonds les exceptions de types exceptionnels et prévu. Le fait de faire des try Catch partout et de rien tester, c'est le cas ou les erreurs ne sont pas prévu et enlève le caractère exceptionnel des exceptions en banalisant leurs interceptions. Mais dans ton cas, faire des tests et générer une exception, c'est une erreur prévu ET exceptionnel en théorie.
j'aurais mi MessageBoxIcon.Information au lieu de MessageBoxIcon.Error
-> Qu'est ce qui t'empêche de le faire ?
ca doit être pour ca qu'on est règles communes de codage, pour pouvoir passer après un autre ^^
-> Carrément !!! ^^
Partager