Constraint error..mais où...

[ampholyte]

Ton test en lui même ne marche pas si l'utilisateur n'entre pas un nombre.

Tu peux caster ton entré, je ne connais pas ADA mais tu pourrais par exemple avoir :

http://fr.wikibooks.org/wiki/Programmation_Ada/FAQ/Le_Langage_Ada#Comment_transformer_une_cha.C3.AEne_de_caract.C3.A8res_en_entier_.3F

Code: Tout sélectionner

var a;
var b;
do {
    a = lireEntree();
    constant Integer := Integer'Value (a); // => trouvé sur le wikibooks
    Si b  11 :
        AfficherMessage("Valeur incorrect, veuillez choisir un nombre entre 0 et 11");
} while (a  11); 



Ici en castant ton entré, si par exemple a est une chaine de caractère le résultat 0 par exemple.
Je te donne également ce lien pour tester la chaine en entrée, avec un peu de recherche, tu trouveras ce que tu veux.
https://docs.google.com/viewer?a=v&q=cache:a6ifEl0TrmMJ:deptinfo.cnam.fr/Enseignement/CycleProbatoire/Vari/chapitres-pdf/chapitre-8.pdf+&hl=fr&gl=fr&pid=bl&srcid=ADGEEShSnjCpA4by9AyviKJlYnbMLeFJkXJ3rXumNFipmQSCcYfYo6CJljApLsYo5mGBTMfLKCa4wE_i_FpTlEx9wUGTngN_Bo8iznu7gv8FNTAuweHYKCpXslb08bh5u7JnvnJsU-of&sig=AHIEtbTtxY4FPLUNSxgafZ615_Pu6iuogA

Tester le programme pour des cas que le programme ne doit pas satisfaire, c'est ballo. Attention de pas tout confondre. Si on veut que ton programme gère les erreurs, alors tu gères les erreurs, si tu le veux pas, tu t'embêtes pas!!!!!

Je suis désolé, mais je ne suis absolument pas d'accord. Pourquoi les fonctions que tu utilises de bibliothèques fonctionnent ? Tout simplement parce qu'elles sont blindées, tu t'imagines qu'un utilisateur lambda va lire tout un README avec tout ce qu'il ne faut pas faire ?

Veuillez ne pas rentrer de nombre supérieur à 11 car sinon le programme crash. Attention la chaîne de caractère ne dois pas contenir plus de 100 caractères sinon ça crash.

Faut se poser 5 min et se dire ce que l'on souhaite faire, surtout pendant les études. Il est important dès le départ de connaître et pratiquer un minimum de sécurité dans un code pour au moins éviter qu'il plante !

Pendant ma scolarité, mes professeurs vérifiaient la solidité d'un code, le programme plantait/crashait => 0 et c'est complètement normal.

Prenons l'exemple d'un jeu vidéo, celui qui n'a jamais voulu essayer de passer à travers un mur invisible ou non me jette la première pierre !
Pourtant dans la vie, tu n'essayes pas de traverser les murs (ou alors faut en parler à quelqu'un :ptdr:). Pourquoi les développeurs se casseraient-ils la tête à gérer les collisions ? Parce que c'est nécessaire. N'as-tu jamais ralé lorsque tu étais parvenu à passer de l'autre côté du mur mais plus moyen de revenir sans faire un quit/reboot du jeu ? N'as-tu pas pesté sur la mauvaise gestion des collisions sur certains jeux ?

Il faut savoir ne pas non plus rentrer dans la paranoia à tester toutes les variables pour être "sur".

Il faut simplement vérifier que ce qui est en entrée est possible. Tu peux très bien pour commencer partir du principe que l'utilisateur rentrera un entier (et non une chaîne de caractère) et tester cet entier pour être sûr qu'il soit dans les bornes attendues.

Lorsque tu ouvres un fichier, tu verifies qu'il soit bien ouvert, qu'il soit présent.

Lorsque tu alloues de la mémoire, tu vérifies qu'il y a de la place disponible sinon tu renvoies un message.

Lorsque tu utilises une fonction tu vérifies que ce qui est renvoyé n'est pas une erreur (-1, NULL il faut voir la doc pour ça).

ce type de comportemenet amène souvent à des usines a gaz.

Sécurisé un minimum son code (même pour des projets persos) pour éviter les crash et les erreurs est déjà un bon début.

Je pars du principe que si en entrée on attend un nombre entre [0; 11], que je tape 12 et que ça crash, c'est que le code n'est pas complet.

Pour finir, chacun à son point de vue mais je persiste à dire que pendant l'étude, il est très important de bien vérifier que son programme ne crash pas, cela permet de prendre les bonnes habitudes.
Libre à toi après de faire ce que tu veux. Un programme qui crash sur une simple erreur de saisie (du même type attendu) est d'après moi un programme qui ne vaut même pas la peine d'être utilisée.

[fatal_error]

encore une fois tu melanges tout.

Il y a une fondamentale difference entre ce que doit faire une fonction et ce qu elle fait.

Si ta fonction doit verifier les saisies utilisateurs, alors tu les verifies.
Si ta fonction ne doit pas verifier les saisies utilisateur, alors elle n'a pas a le faire.

Lorsque tu ouvres un fichier, tu verifies qu'il soit bien ouvert, qu'il soit présent.

Et si c'est pas le cas, tu fais quoi
Comprends bien que tu nes pas cense coder comme tu le penses. En theorie, si tu fais bien les choses, tu as:

Code: Tout sélectionner

//Ouvre un fichier de path absolu nomFichier
//Si a pu etre ouvert, retourne File* pointant sur le fichier ouvert
//Sinon return NULL
File* maFonctionQuiOuvreLeFichier(string nomFichier)

Code: Tout sélectionner

//Ouvre un fichier de path asbsolu nomFichier
//nomFichier doit correspondre a un fichier existant
File* maFonctionQuiOuvreLeFichier(string nomFichier)

Il est evident que dans le second cas, la verification est faite en amont, mais rien ne t'obliges dans maFonctionQuiOuvreLeFichier a refaire la verification ...... si tu veux la refaire libre a toi, mais ce n'est pas exigeable.

[ampholyte]

Sauf que dans ton second cas, si l'utilisateur fait une faute de frappe (ce qui peut arriver à tout le monde), le programme crash et il ne sait pas pourquoi, personnellement je n'aime pas cette façon de faire, j'aime avoir un message d'erreur m'indiquant ce qui c'est passé => "Error : file not found" et fermer le programme par exemple.

Tout ce que j'ai pu dire avant n'est que mon avis, ma façon de faire et ma méthode de développement que ce soit perso ou non. Chacun est libre de penser ce qu'il veut et de faire comme il le sent.

@Rockleader : A toi de te forger ton propre avis sur la question et de voir ce que tu préfères.

[Rockleader]

Pour ma part je pense que tout dépend du contexte; il y a des programmes qu'il faudra quoi qu'il arrive sécurisé. J'imagine bien un mec dans sa fusée on lui demande d'appuyer sur une touche disont numérique et il entre un caractère, si le programme qui gère le vol de la fusée nous fait un crash à ce moment là ça pue --'

Donc oui il faut pouvoir sécuriser un code, ou du moins il faut pouvoir en être capable.


Faut il le faire pour autant à chaque fois je ne pense pas.


Comme le dit fatal sur un projet minime...si tu demandes au mec quel age a tu et qu'il te répond Oui ben qu'est ce que tu veux que je te dise...il y a bien quelques test qu'on peut faire dans le genre redemander l'age tant qu'on a pas un truc compris entre 1 et 110 ...mais si tu as Oui tu fais quoi --' Sa te ferait sortir des lignes et des lignes de codes pour gérer cette erreur alors qu'au final tu n'en a rien à faire...



Dépend de la situation voilà tout.

Dans mon cas à partir du moment où j'indice à l'affichage les numéros de lignes et de colonne; bah si le gars sors de l'intervalle j'y peut rien...je redemande pour sécuriser et qu'il n’être pas trop de connerie; mais s'il dépasse ma B_INF-epsilon..B_SUP+epsilon où epsilon représenterait l'erreur due à l'innatention de l'utilisateur alors oui s'il n'entre pas un truc là dedans ça crashe.

Mais tant que le gars reste dans l'intervalle ci dessus et que pour autant il est pas entre B_INF et B_SUP alors oui là on peut sécurisé en redemandant la ligne en pensant qu'il s'agit juste d'une erreur de frappe; du genre t'appuies sur 8 au lieu de 7.

[Dlzlogic]

Bonjour Rockleader,
Comme vous vous en doutez, je ne peux qu'appuyer les explications d'Ampholyte, mais je crois qu'il a tout dit.
Par contre, je vous donnerais un petit conseil, puisque vous débutez dans l'informatique, je dirai même "grand débutant", cherchez plutôt à assimiler les notions qui vous sont données, il sera temps plus tard de donner votre avis.
Je me souviens de votre réaction à propos du "or" et "and", vous m'avez dit "c'est pas logique", alors que vous auriez dû chercher jusqu'à comprendre pourquoi c'était bien "and" et non pas "or".

En tout cas, bonne continuation.

[Rockleader]

Je me souviens de votre réaction à propos du "or" et "and", vous m'avez dit "c'est pas logique", alors que vous auriez dû chercher jusqu'à comprendre pourquoi c'était bien "and" et non pas "or".

:lol3: C'est bien vrai^^

mais niveau algèbre de Boole je commence à gérer un peu mieux notamment grâce à mes cours d'info numérique (même si j'ai eu 4 au partiel :hum: )

Notamment je commence à être un peu plus sur de certaine chose du genre

Je n'écrirais plus pour une boucle While (finie = FALSE) je ferais tout simplement While (not finie)

Puisque l'on peut représenter toutes les fonction à partie de Nand et de Nor.

[fatal_error]

c'est pas top de faire des doubles négations, mieux vaut ecrire while(continuer)....