syntaxe do try

Version imprimable

syntaxe do try

bonjour à tous, j'ai essayé ce petit bout de code et il s'avère que ça compile:

Code:

1
2
3
4
5
6
7
8
9
do try
    {
        //mon code
    }
    catch (std::invalid_argument const& exception)
    {
        std::cerr << "invalid argument: " << exception.what() << std::endl;
        error = true;
    }while (error);

est-ce que c'est une hérésie?

Bonjour,

Ce code ne pose pas de problème:
Le syntaxe du do c'est do statement while ( expression ); et le try {} et ses catch(){} est bien un "statement".
On peut aussi retrouver cette syntaxe dans :
Code:

1 2 3 4 int fct() try { } catch (...) { }
Maintenant, utiliser des accolades supplémentaires est peut-être plus lisible.

Le seul cas où on ne peut pas ajouter d'accolades de lisibilité, c'est dans un constructeur :
Code:

1 2 3 4 5 6 7 8 struct Machin : public Base { std::string nom; Machin() try : Base(1) , nom("hello") { } catch (...) { std::cout << "exception pendant la construction de Machin ou de ses composants"; throw; } };

18/07/2020, 19h54
koala01

2 pièce(s) jointe(s)
Salut,

Tu devrais prendre l'habitude de faire un code qui soit d'abord et avant tout lisible par l'humain, bien avant d'arriver à faire un code qui fonctionne ;)

Je m'explique:

Quelqu'un de sans doute bien plus intelligent que moi a dit un jour que

Citation:

La qualité d'un code s'évalue au nombre de WTF's à la minute

Pièce jointe 575320

Il a tout à fait raison, car, bien que l'idéal reste malgré tout d'avoir un code qui puisse être compris par le compilateur, ce n'est pas le compilateur qui devra le modifier s'il s'avère qu'il est incorrect: c'est la personne qui lira le code.

Donnes moi un code bien écrit qui ne fonctionne pas, et, comme je serai en mesure de le comprendre, je serai -- a priori -- en mesure de le corriger.

Donnes moi un code mal écrit et, même s'il fonctionne, je perdrai tellement de temps à essayer de le comprendre que j'aurai sans doute plus facile de le réécrire.

Prends un code mal écrit qui ne fonctionne pas, et tu es sur de perdre des heures à essayer de comprendre pourquoi il ne fonctionne pas, et comment le corriger ;)

Mais donc, tu veux un do while et tu veux gérer les exceptions à l'intérieur de cette boucle :question:
Fais donc les choses dans l'ordre, sous la forme de
Code:

1 2 3 4 5 6 7 8 9 10 11 bool error{false}; do{ try{ /* ... */ error=false; } catch(...){ /* ... */ error = true; } }while(error);
après tout, cela reviendra au même dans le code binaire exécutable final.

Par contre, la structure du code en elle-même permet au lecteur (ce pourrait être toi, dans trois mois, six mois ou un ans) -- qui n'a aucune idée de ce que tu cherchais à faire -- de comprendre le but que tu recherches aujourd'hui, et qui te semble -- aujourd'hui -- tellement clair que tu crois pouvoir le "compacter".

Le problème avec cette approche du "code le plus compact possible", c'est que, demain, tu vas t'attaquer à un autre problème, puis encore à un autre, au point que tu vas t'attaquer, avec le temps à tellement de problèmes différents, qui "chasseront" à chaque fois le dernier problème réglé que tu ne peux pas espérer te souvenir des spécificités propres à un problème sur plus de ... quelques heures.

Tu dois donc partir du principe que tu n'est le développeur d'une fonctionnalité quelconque que le temps strictement nécessaire à en écrire le code et à en valider le fonctionnement.

Après ce délais, tu deviens automatiquement un utilisateur de la fonctionnalité. Or, l'utilisateur ne regardait pas au dessus de ton épaule pendant que tu écrivait le code. Il n'a donc, a priori, aucune idée de ce que pouvaient être tes intentions à ce moment là ;)
18/07/2020, 20h08
aperikub

en fait j'avais tenté cette syntaxe justement parce que ça me paraissait très clair au niveau grammaire (grammaire anglaise, pas grammaire de programmation) dans le sens:

do try
{
//what i need to do

}while(//it isn't done)

quasiment à chaque fois que j'utilise un try/catch j'ai aussi besoin dune boucle au cas ou l'exception soit levée mais bon c'est clair de mon point de vue et je n'ai probablement pas encore le niveau pour voir les éventuelles confusions possibles,

Il faut te dire que, plus tu suis un raisonnement "biscornu" aujourd'hui, moins tu as de chances de le retrouver plus tard... Et moins ceux qui n'étaient pas avec toi lors de l'écriture du code ont de chance de le faire.

C++ dispose, entre autres, de règles de syntaxe très strictes. Si bien que personne ne devra réfléchir à la signification d'un code proche de
Code:

1 2 3 4 5 6 7 8 9 10 do{ /* ce qui ne risque pas d'échouer */ try{ /* ce qui risque de lancer une exception */ } catch(/* ... */){ /* si on a les moyen de gérer l'exception lancée */ } /* ce qui peut fonctionner après, sans risque de lancer d'exception */ } while(condition);
car il est clair que le bloc try ... catch fait partie "d'un tout" qui sera -- au besoin -- répété plusieurs fois, et qui peut -- éventuellement -- contenir des éléments qui n'ont aucun besoin d'être traités par le bloc try catch.

Il se fait que C++ est aussi "relativement" laxiste sur certains points, si bien qu'un code proche de
Code:

1 2 3 4 5 do try{ /* ... */ }catch(..){ /* ... */ }while(condition);
fonctionnera également, à ceci près que le lecteur perd alors une information capitale c'est l'ensemble du bloc try...catch qui sera exécuté potentiellement plusieurs fois.

De plus, cette syntaxe "admise" présente un autre inconvénient majeur: il n'y a aucun moyen pour ajouter des éléments en dehors du bloc try ou du bloc catch, car, si tu te retrouve avec un code proche de
Code:

1 2 3 4 5 6 7 do doSomethning(); try{ /* ... */ } catch(std::runtime_error & e){ /* ... */ }while(again);
tu vas atteindre les limites de la permissivité du compilateur et te faire engueuler :D

Du coup, on se rend "assez facilement" compte que, ben, ce n'est pas vraiment pour le temps que cela prend d'ajouter une paire d'accolades, et qu'il est largement préférable de les mettre, y compris là où elles ne sont pas forcément obligatoires ;)

PS: au passage, la notion d'exception est une notion qui, a priori, indique qu'un événement contre lequel le développeur n'a absolument aucun moyen de se protéger risque d'arriver (de manière exceptionnelle!!!):

parce que le fichier demandé n'existe pas
parce qu'un fou furieux s'est mis à couper tous les câbles réseau
parce que le serveur wifi est tombé en panne
parce qu'un fichier ne respecte pas ses spécifications
j'en passe, et peut-être de meilleures

CE n'EST PAS le genre de truc que tu devrais utiliser pour savoir si l'utilisateur a bel et bien introduit un entier quand tu le lui as demandé ;)

Et CE N'EST PAS non plus le genre de truc que tu dois utiliser pour tenir compte de l'incompétence des développeurs: si tu as une précondition qui doit être respectée, tu peux lui donner forme à l'aide des assertions ;)