Je me suis mis au C# depuis un petit mois et je m'en sors pas mal jusque là, mais je rencontre un problème que je ne sais pas résoudre. Je sais qu'il y a tout un tas de protection, du coup je me demande si les effets de bords sont encore possibles ? Je suis plutôt C ou c'est assez fréquent.
J'ai une appli de type "form", un bouton ouvre l'invitation à ouvrir un fichier. Sur certains fichiers, ça fonctionne, sur d'autre la fenêtre reste ouverte sans pour autant appeler "openSrcFile.ShowDialog()" selon le point d'arrêt qui n'arrête rien. Cependant, je peux voir que l'opération sur le fichier est effectuée dans le log comme lorsque ça fonctionne normalement.
private void SrcFileSelect_Click(object sender, EventArgs e)
{//bouton demande d'ouverture de fichier
if (openSrcFile.ShowDialog() == DialogResult.OK)
{
try
{
//nom dans la textbox fichier
textBox1.Text = openSrcFile.FileName;
}
catch (SecurityException ex)
{
MessageBox.Show($"Security error.\n\nError message: {ex.Message}\n\n" +
$"Details:\n\n{ex.StackTrace}");
}
}
}
private void openFileDialog1_FileOk(object sender, EventArgs e)
{//sélection de fichier réussie
//on va chercher l'extension de fichier
string fileExt = FetchFileExt(openSrcFile.FileName).ToLower();
switch (fileExt)
{
case "db":
case "udt":
convertToTia = false;
break;
case "l5x":
convertToTia = true;
break;
default:
return;
}
if (!convertToTia)
{//Tia -> Rockwell
FStoreToBuffer(); //mise en buffer du ficher / nettoyage
TiaBuild();//mise au format depuis fichier TIA
}
else
{//Rockwell -> Tia
//Load xml
//charger structures
rockStructFormat(); //mise au format depuis fichier Rock
}
destBtn.Visible = convertToTia;
}
Je n'arrive jamais à m'en sortir au debug, du coup, je dois commenter mes derniers ajouts pour voir ce qui crée ce souci, mais c'est le plus souvent un truc qui n'a rien à voir, genre une fonction qui reçoit un argument négatif quand c'est pas prévu pour, ou autre.
Je suis sous visual studio que je ne connais pas très bien non-plus donc j'en suis au debug de base avec les points d'arrêt et la pile d'appel qui est infernale à déchiffrer tellement il y a de couches.
Les effets de bords sont-ils encore possibles, et existe-t-il de quoi les repérer avec le débugeur ?
Un effet de bord est généralement une modification involontaire de code ou de donnée lors de l'exécution, le plus souvent (en C) par des débordement de mémoire, comme des index de table qui "dépassent".. Quand on écrit où on ne devrait pas en mémoire.
Heu, le Try/catch vient direct du site Microsoft qui est en aide de la méthode, du coup.. Mais je comprends, c'est ptêt abusif, mais comme ça semblait déconner je cherchais un moyen de lever une alarme ou un truc qui m'aiderait.
bacelar a écrit:
Je vois des accès à des propriétés de contrôles graphiques ; pour un non habitué, quand on fait du multithreading, c'est assez piégeux.
Etes-vous bien en "Debug" ?
Je suis en DEBUG, oui. Et effectivement il semble y avoir beaucoup de multi threading tellement ma pile d'appels est remplie d'infos inexploitables ^^. Je suis un lapin de 3 semaines dans l'histoire, je n'y connais rien, donc pour l'instant, je suis encore en mode "je bricole comme je peux". à priori, les accès aux propriétés de contrôles graphiques fonctionnent et ne lèvent aucun warning. Je ne suis pas encore au fait de l'état de l'art avec ce langage.
bacelar a écrit:
"FetchFileExt", vous semblez réinventer des roues carrées : [..]
Pour l'extension, je suis habitué à tout faire moi-même, désolé si au bout d'un mois je ne connais par par cœur les 5000 libs ni les 6 millions d'objets et méthodes existants, mais merci pour l'info. Puis bon, sortir une extension de fichier, ça me prend 1 minute à implémenter moi-même alors que je vais prendre 30 minutes à trouver le truc qui existe déjà dans l'océan d'objets et de méthodes de la doc. C'est un peu le souci du haut niveau quand on ne connaît pas bien.
là, je n'ai pas trouvé ce qui cause le problème, mais le coup d'avant c'était parce que je cherchais une chaîne dans le fichier et que j'atteignais la fin de fichier sans l'avoir trouvée. Une fois le fichier formatté correctement, ça a résolu le problème. On se demande quel est le rapport avec la fenêtre d'invit de sélection de fichier ? Je suis très certainement pas très carré sur mes gestions d'erreurs, mais ça n'a quand-même rien à voir. Puis franchement, il y a des trucs qui lèvent jusqu'à 10 exceptions, je peux pas passer mon temps à tout traiter.
Je suppose que ce cette fois, c'est un autre truc du genre, mais comme le rapport n'est pas évident, ça pourrait être n'importe quoi..
EN y repensant, je ne pense pas que la fenêtre soit de nouveau ouverte, elle n'est simplement pas fermée. Parce que le fichier résultant de la translation est produit, donc le fichier choisi est bien ouvert et traité.
Ok, désolé, j'avais pas vu que c'était un try/catch sur "SecurityException" et pas sur "Exception".
C'est une erreur extrêmement répandue chez les programmeurs nouveaux dans la POO (rapport avec votre background "C", procédural) de "tout" try/catch (Exception) en ayant un sentiment de fausse sécurité.
C'est pas top de faire des try/catch sur "SecurityException" mais les cas d'usage de la méthode "ShowDialog()" peuvent, peut-être, demander le traitement systématique de ce type d'exception.
Mais je suis assez dubitatif car des cas de déclenchement de cette exception "SecurityException" ont des chances de faire aussi capoter la fonction "MessageBox", comme l'exécution en temps que "Service Windows". Et des exceptions qui se déclenchent dans des "catch", c'est jamais très bon.
Donc cf. la documentation de cette méthode, mais attention aux exemples qui y sont donnés, car c'est rarement des "exemples" à suivre, car c'est plus la concision et la simplicité que l'"exactitude"/robustesse qui pilotent ces exemples.
Pour simplifier la mise au point du programme (rapport au débuggeur) et aussi son monitoring, n'utiliser les try/catch que dans les cas qui le nécessite vraiment. Mettre des try/catch "partout", c'est beaucoup d'emmerdes.
Votre définition d'"effet de bord" est très restrictive. Des trucs comme la modification des lignes de cache dans le processeur peuvent être considérés comme un effet de bord. Et dans ce cas, C# n'y échappe absolument pas. Avec votre définition, c'est plus la manière de programmer que le langage ou le runtime .NET qui réduit la possibilité d'effet de bord.
En C, lire "hors limite" dans un tableau, ça fait peut-être péter une GPF (General Protection Fault) mais la majorité du temps, c'est pas détecté, sauf mise en place de bibliothèques systèmes dédiées (sanitizers). En C#, c'est une exception dans les dents, systématiquement. Donc, "l'effet de bord" existe mais le comportement est radicalement différent.
Et si vous utilisez des mécanismes "très avancées", comme le "pinnage" d'objet, la sérialisation d'objet inter-programme, etc... ; vous pouvez aussi vous retrouvez dans les cas restrictifs de votre définition.
Donc attention, c'est plus la "philosophie" des langages .NET qui les rendent sûrs. Si vous utilisez vos habitudes du C "historique"/embarqué, vous pouvez toujours vous tirez une balle dans le pied (mais l'effet de cette balle sera différent).
Et dans la "philosophie" des langages .NET, comme dans tout langage "Objet", c'est l'utilisation des fonctionnalités des objets, qui ont été testées et retestées, qu'il faut utiliser. Je fais ici référence à votre roue carrée de "FetchFileExt" qui vraisemblablement ne gérera pas la mention de "canaux" de fichier dans la chaine passée en paramètre, etc....
L'utilisation de classes comme FileInfo ou Path permettent de très facilement gérer TOUS les cas, même ceux que vous ne connaissez pas, mais que les implémenteurs de ces classes ont gérés pour vous.
Un simple "Ctl+Espace" dans l'éditeur de code de Visual Studio permet d'avoir la liste des méthodes, ou des champs d'un objet/variable. Et leur nom sont conçu pour être "informatifs" sur leur utilisation (affordance). Donc "par cœur les 5000 libs ni les 6 millions d'objets et méthodes existants", comment dire ? Faut juste bien prendre les "bons" types/classes, et pas être nostalgique des roues carrées des années Disco (1970).
Si vous n'abandonnez pas vos paradigmes du C "historique"/embarqué, vous ne serez pas beaucoup plus en sécurité en .NET qu'en C "de base". (Et vous n'y serez pas plus productif non plus.)
Comme le mentionne @umfred, et que la mise en rouge de toute la ligne dans le débuggeur "cache" ; un point d'arrêt dans Visual Studio se fait au niveau d'une "expression" et pas d'une ligne entière. Donc, évitez, autant que possible, des lignes de code "complexe" ("if (openSrcFile.ShowDialog() == DialogResult.OK)", c'est déjà : un appel de méthode + une comparaison + un saut de branche). Et, si possible, de mettre les points d'arrêt en début de ligne.
>mais ça n'a quand-même rien à voir. ...<
C'est bien plus compliqué de "désapprendre/s'adapter" que d'apprendre "from scratche". Vous vous trouvez dans des situations où l'usage "orthodoxe" des guidelines .NET devrait vous évitez ces "prise de tête". (multi-threading, gestion d'erreur "invisible", outillage de productivité, etc...)
Il est assez probable que vos difficultés viennent de vos reflexes cognitifs plus que d'une éventuelle complexité inhérente de l'environnement .NET. Beaucoup de débutant commencent par .NET et ne galère pas avec le débuggeur.
Si vous êtes plus précis sur vos difficultés, nous pourrions peut-être voir quels reflexes cognitifs/ idées préconçues vous avez qui "complexifie" inutilement votre vue de C#/.NET.
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
J'ai fini par résoudre le souci. Il s'agissait d'un problème de comparateur plus loin dans le code (dans la fonction TIABuild plus exactement) qui exécutait des fonctions qui ne pouvaient pas bien se dérouler puisqu'elles n'auraient pas du être exécutées.
Du coup, je me dis que j'étais probablement coincé dans openFileDialog1_FileOk() et que la fenêtre ne se fermait pas parce que je n'en sortais pas. C'est la seul explication que je trouve, parce que la correction n'a vraiment absolument aucun rapport avec cet objet.
Bacelar a écrit :
L'utilisation de classes comme FileInfo ou Path permettent de très facilement gérer TOUS les cas,
Ok. Mais encore faut-il savoir que ces classes existent. Aucune nostalgie dans l'histoire. J'utilise les classes quand je sais qu'elles existent, puisque c'est exactement pour cette raison que je m'oriente vers un langage prémâché.
Je suis allé au bout des cours Microsoft (learn), et maintenant je n'en sais pas plus que ça. à part les quelques points communs avec les autres langages. Et oui, j'imagine bien qu'abandonner plus de 30 ans de procédural va être compliqué, mais je n'ai pas vraiment d'autre exigence que "ça fonctionne" pour l'instant. Et j'ai encore des bases plus basiques à acquérir : intégrer les syntaxes (ternaires, nulls), les gestions bizarres de null justement, créer une classe cohérente etc. Plutôt que de me soucier du multi-threading et de la mécanique d'exécution du langage.
Mais je vais apprendre. Quand je vois le code de mon premier jeu en C d'il y a 15 ans, je m'insulterais si je croisais le moi de l'époque. Je suis là sur mon tout premier projet en C#, en dehors de "hello world" et des exercices très naïfs de Microsoft.
Je vais tenir compte de tous les conseilles, alors Merci.
Bacelar a écrit :
Donc, évitez, autant que possible, des lignes de code "complexe" [...]
Tout à fait, c'est vrai que je n'y ai pas pensé sur ce coup là.. J'ai un peu trop pris l'habitude de mettre du code dans le code, il y a bien pire plus loin .
Bonhomme !! | Jeu de plateforme : Prototype.
Bonhomme !! | Jeu de plateforme : Prototype.
Bonhomme !! | Jeu de plateforme : Prototype.
Bonhomme !! | Jeu de plateforme : Prototype.