IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Windows Forms Discussion :

Erreur un peu déroutante


Sujet :

Windows Forms

  1. #1
    Membre émérite
    Profil pro
    Développeur Web
    Inscrit en
    Février 2008
    Messages
    2 637
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Février 2008
    Messages : 2 637
    Par défaut Erreur un peu déroutante
    Bonjour tout le monde,

    Un bon paquet de fois, j'ai vu mon application de diaporama afficher ceci à la sélection d'un élément de la liste, c'est-à-dire tellement souvent qu'entre deux messages il n'y a pas moyen de voir autre chose :

    System.Text.EncoderFallbackException: Impossible de traduire le caractère Unicode \uD83D à l'index 106 vers la page de codes spécifiée.
    Donc, pas de ligne de code, à peine le moment où ça se produit pour deviner le contexte.

    En appuyant sur la touche Entrée comme un bourrin, j'ai fini par saturer la gestion d'erreur et obtenir enfin une erreur non gérée, qui me permettait d'en savoir plus.

    Pour finir dans listBox1_OnSelectedIndexChanged, j'ai ajouté ça :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    catch(System.Text.EncoderFallbackException stefbe)
    {
        string str = stefbe.Message;
    }
    Je peux laisser les accolades vides puisque c'est pour ignorer le cas, le code à l'intérieur c'est pour pouvoir y mettre un point d'arrêt pour essayer de mieux comprendre (un de ces jours).

    La première fois impeccable, puis il a fallu que je fasse la même chose un peu plus loin dans le code, et cette fois c'était assez curieux : tant que j'exécute sous Visual Studio ça se passe bien, si j'exécute le programme de façon indépendante il m'affiche de nouveau des messages d'erreur.

    Bon j'y reviendrai.

    Là maintenant, peut-être ai-je un peu noyé le poisson, ce qui me préoccupe est le contrôle de versions.

    Une fois que mon code me semble correct j'essaie de pousser vers Git, et là ça se gâte.

    Le Push échoue sur semble-t-il un problème de droits d'accès.
    Je trouve ça ballot, parce que le dépôt initial est dans le répertoire de développement, dans "C:\Projects Visual Studio\WinForms", et le dépôt "distant" dans un autre répertoire à côté, dans "C:\Projects Visual Studio\NewRepo". Mince, si je n'ai pas le droit d'écrire là-dedans, ben qui alors ?

    J'ai regardé dans l'onglet sécurité du répertoire du dépôt initial, il faut être authentifié pour modifier. Authentifié à ce niveau, ça veut dire avoir ouvert une session Windows, pas vrai ?

    Je suppose que c'est assez facile à deviner que pour ouvrir Visual Studio, il faut avoir ouvert une session Windows.

    Je me suis quand même "connecté à Visual Studio", pourtant dans le volet des modifications Git, on me dit "Aucun changement non indexé dans le répertoire de travail", alors que dans la barre d'état je vois 20 validations sortantes, 0 entrantes. Il reste donc à mettre ce monde-là d'accord.

    Au demeurant, en haut de l'onglet de modifications Git, je vois un message :
    Impossible de traduire les octets [E8]
    à l'index 181 à partir de la page de
    codes spécifiée en Unicode.
    Ah, finalement, je me demande si j'ai tant que ça noyé le poisson ...

    Est-ce que quelqu'un réussit à ne pas se noyer dans ce que j'ai dit ?

  2. #2
    Expert confirmé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 325
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2005
    Messages : 5 325
    Par défaut
    Je comprends pas trop votre problème Git.

    On va se concentrer sur le problème des exceptions.

    Vous semblez assez à laisse pour faire les méthodes de bourrin mais vous ne donnez pas des éléments essentiels pour comprendre la situation.
    Vous êtes nouveau dans .NET ?

    Que le comportement du programme quand il est en "debuggee" du débuggeur de VS soit légèrement différent que lors d'une exécution "libre", c'est des choses qui arrivent et qu'il faut gérer "intelligemment".

    "System.Text.EncoderFallbackException", c'est une exception géré en interne, avec des traces dans la fenêtre "Sortie" de VS, ou qui "pope" quand il est "debuggee" sous VS, parce que vos réglages du débuggeur sont en mode "paranoïaque" ?
    Ou est-ce une exception qui pope lors d'une exécution "libre" ?

    Si c'est le 2ème cas, configurez votre débuggeur pour qu'il s'arrête systématiquement lors du lancement de ce type d'exception (le rendre "paranoïaque"), pour voir d'où vient la cochonnerie que vous avez envoyé dans ces malheurs contrôles ou chaines de caractères.
    La CallStack est ton amie.

    Pouvez-vous mettre sous Github ou Gitlab un projet qui reproduit le problème ?

    Donc, on oublie les catch "à la con" pour faire du débugging à l'arrache, SVP.

    Là maintenant, peut-être ai-je un peu noyé le poisson,
    Faut se méfier des fantômes de poisson noyé, ça a des arêtes venimeuses.

    Pour Git, c'est peut-être un nom de fichier avec des caractères "non valides", non ? (encore une histoire de cochonnerie de caractères invalides )

  3. #3
    Membre émérite
    Profil pro
    Développeur Web
    Inscrit en
    Février 2008
    Messages
    2 637
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Février 2008
    Messages : 2 637
    Par défaut
    Hum, je dirais que ce serait peut-être une coquetterie de me dire nouveau sur .Net, ma certif remonte quand même à 2008.

    Mon programme fonctionne depuis quelques années, avec un peu d'évolution de temps en temps. C'est avec une liste d'images que je lui file en paramètres, qu'est apparue l'erreur d'encodage. Avec les autres listes, pas de problème.

    Donc il faudra bien que je creuse un peu. Si c'était avec un nom d'image ou deux ça serait bien plus simple à creuser, j'ai ainsi eu l'occasion de développer le support des jeux de caractères, du coup par défaut je mets UTF, je ne sais plus peut-être bien UTF32.

    Mais là, l'erreur se produit sur toutes les images, et pas mal de noms ne sont pas si exotiques que ça. En l'ignorant avec un try...catch ça marche, c'est vrai qu'il y a cette particularité que dernièrement ça marche surtout en mode débogage.

    Maintenant que j'ai le moyen de mettre un point d'arrêt sur l'exception, je pourrai regarder davantage ce qu'elle a dans les tripes. Mais j'ai anticipé que ça pouvait être assez chronophage, c'est pour ça que je ne l'ai pas fait tout de suite.

    Du coup ça m'aurait bien arrangé de pouvoir progresser au sujet de Git, parce qu'avancer sans contrôle de version, c'est un peu comme pour un funambule de travailler sans filet, tant qu'il ne tombe pas c'est bon ...

    Bon il y a un forum dédié, je vais y mettre un petit coucou.

    J'ai bien l'impression effectivement que de temps en temps j'ai affaire aux arrêtes de poisson noyé, pauvre bête ce n'est pas fameux comme voisinage.

  4. #4
    Expert confirmé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 325
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2005
    Messages : 5 325
    Par défaut
    C'est avec une liste d'images que je lui file en paramètres, qu'est apparue l'erreur d'encodage.
    Pourquoi c'est un Encoder TEXTE qui gueule alors, si c'est des images ???

    Catcher ces exceptions, c'est vous mettre des bâtons dans les roues, car vous ne savez plus où et pourquoi le problème est survenu.
    On ne catche que les exceptions que l'on gère.
    Coller un point d'arrêt, comme la loguer, ce n'est pas la traiter.

    Vérifiez dans la configuration du débugueur que le lancement de ce type d'exception interrompt le debuggee.
    Il faudra peut-être configurer le serveur de symboles pour avoir des détails sur les valeurs des paramètres, car il y a de bonnes chances que c'est dans le corps du Framework que cela "hurle".

    j'ai ainsi eu l'occasion de développer le support des jeux de caractères
    Je comprends pas trop. .NET est en UTF-16, "de base".

    Si vous n'arrivez pas à "recréer" le problème avec un débugueur mais seulement avec une exécution "libre", rien ne vous empêche d'attacher le débugueur au moment de l'apparition de la fenêtre d'erreur.
    Mais pour cela, faut pas avoir catché à tord et à travers ces exceptions.

    Maintenant que j'ai le moyen de mettre un point d'arrêt sur l'exception, je pourrai regarder davantage ce qu'elle a dans les tripes.
    Bin non, Vous n'avez plus que les informations contenues dans le message de l'exception et plus le contexte de lancement de l'exception.

    Je pense qu'en analysant le LANCEMANT de l'exception, la cause sera triviale.

    Vous pouvez poster votre exécutable ici, en donnant la marche à suivre pour le faire "crasher" ?

  5. #5
    Membre émérite
    Profil pro
    Développeur Web
    Inscrit en
    Février 2008
    Messages
    2 637
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Février 2008
    Messages : 2 637
    Par défaut
    Citation Envoyé par bacelar Voir le message
    Pourquoi c'est un Encoder TEXTE qui gueule alors, si c'est des images ???
    La liste contient les noms des images.
    Et ça, effectivement, c'est du texte.

    Catcher ces exceptions, c'est vous mettre des bâtons dans les roues, car vous ne savez plus où et pourquoi le problème est survenu.
    On ne catche que les exceptions que l'on gère.
    Coller un point d'arrêt, comme la loguer, ce n'est pas la traiter.
    Effectivement tant que c'était de l'erreur gérée je n'avais pas trop d'info.
    L'intérêt avec le point d'arrêt, c'est que je peux avoir toutes les propriétés de l'exception, ne serait-ce qu'en mettant le curseur de la souris dessus, et au besoin ajouter du code pour savoir sur quelle ligne ça s'est produit, même si ça prend plus d'un instant.

    Vérifiez dans la configuration du débugueur que le lancement de ce type d'exception interrompt le debuggee.
    Il faudra peut-être configurer le serveur de symboles pour avoir des détails sur les valeurs des paramètres, car il y a de bonnes chances que c'est dans le corps du Framework que cela "hurle".
    Ça finira peut-être par désactiver la détection de l'exception en question, si il se confirme qu'elle n'est pas susceptible de créer un problème ailleurs. Je ne l'ai pas vue arriver, alors s'agit pas de me laisser surprendre si le problème se pose ailleurs.


    Je comprends pas trop. .NET est en UTF-16, "de base".
    C'est bien possible. J'ai dit ça de mémoire, en me disant que j'ai dû vouloir assurer le support du plus de caractères possible, et que logiquement ça c'était en UTF32 que j'allais l'obtenir, mais effectivement c'est sous réserve que ça soit sans cabrioles au-delà du nécessaire. Ça remonte à plusieurs mois, alors j'ai un peu oublié les détails.

    Si vous n'arrivez pas à "recréer" le problème avec un débugueur mais seulement avec une exécution "libre", rien ne vous empêche d'attacher le débugueur au moment de l'apparition de la fenêtre d'erreur.C
    Mais pour cela, faut pas avoir catché à tord et à travers ces exceptions.
    Au départ il y avait un catch tous azimuts, qui permettait de savoir qu'il y avait une exception, et quel type d'exception. Mais logiquement, dans le titre du message j'aurais dû mettre plus d'éléments pour dire où ça se passe.
    Du coup maintenant j'ai catché l'erreur exacte. Ça va mieux, ça peut fonctionner dans certaines circonstances. Après il faudra prendre le temps de regarder ce que l'exception a ... "dans les tripes". Il y a bien les arêtes du poisson noyé, là il va falloir regarder les tripes de l'exception.

    Bin non, Vous n'avez plus que les informations contenues dans le message de l'exception et plus le contexte de lancement de l'exception.

    Je pense qu'en analysant le LANCEMANT de l'exception, la cause sera triviale.
    Si je ne mets que le texte de l'exception, effectivement, ce n'est pas très causant.
    Une fois qu'il y aura un point d'arrêt dessus, je peux avoir toutes ses propriétés, ça peut en dire déjà plus. Après il y a moyen de savoir la ligne où ça se passe, enfin si je me rappelle bien c'est plutôt la ligne la plus proche où a été définie une certaine variable.

    J'imagine mal que ça se fasse dans l'heure, mais il y a moyen de savoir.

    Vpus pouvez poster votre exécutable ici, en donnant la marche à suivre pour le faire "crasher" ?
    Si jamais je ne m'en sors pas, ça va peut-être finir comme ça, merci.

  6. #6
    Expert confirmé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 325
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2005
    Messages : 5 325
    Par défaut
    Ok, les 2 problèmes sont vraisemblablement liés, avec des noms de fichiers "invalides".

    Utilisez le raccourci "Ctrl+alt+E" dans Visual Studio pour ouvrir le paramétrage des exception.
    Dans ma configuration, par défaut, "System.Text.EncoderFallbackException" n'est pas une des exception qui interrompt le debuggee.
    Cochez la case correspondant dans la fenêtre "Paramètres d'exception" pour que le débuggeur arrête le debuggee dés le lancement de l'exception.
    Dans votre "catch" la pile d'appel est déjà repliée, les finally exécutés, les variables "using" libérées, etc...
    Avec ces réglages, vous n'avez besoin d'ajouter aucun code.
    Les espions et la fenêtre "immediate" permet de voir ce qui se passe.

    Même en UTF32, il y a des séquences de bits qui ne correspondent pas à des caractères valides, et encore moins si c'est des noms de fichier qui doivent être acceptés par le système de fichier en question.

    Après il faudra prendre le temps de regarder ce que l'exception a ... "dans les tripes".
    Si vous configurez correctement "Paramètres d'exception", vous avez automatiquement les tripes de l'exception (callstack, stacktrace, variables, threads, ...)

  7. #7
    Membre émérite
    Profil pro
    Développeur Web
    Inscrit en
    Février 2008
    Messages
    2 637
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Février 2008
    Messages : 2 637
    Par défaut
    Citation Envoyé par bacelar Voir le message
    Ok, les 2 problèmes sont vraisemblablement liés, avec des noms de fichiers "invalides".

    Utilisez le raccourci "Ctrl+alt+E" dans Visual Studio pour ouvrir le paramétrage des exception.
    Dans ma configuration, par défaut, "System.Text.EncoderFallbackException" n'est pas une des exception qui interrompt le debuggee.
    Cochez la case correspondant dans la fenêtre "Paramètres d'exception" pour que le débuggeur arrête le debuggee dés le lancement de l'exception.
    mais on dirait que ... j'ai la même chose. Normal, je n'y ai pas touché non plus.

    Nom : TextExceptions  Capture d'écran 2025-02-04 015223.png
Affichages : 34
Taille : 32,8 Ko

    Dans votre "catch" la pile d'appel est déjà repliée, les finally exécutés, les variables "using" libérées, etc...
    Avec ces réglages, vous n'avez besoin d'ajouter aucun code.
    Les espions et la fenêtre "immediate" permet de voir ce qui se passe.

    Même en UTF32, il y a des séquences de bits qui ne correspondent pas à des caractères valides, et encore moins si c'est des noms de fichier qui doivent être acceptés par le système de fichier en question.
    C'est mieux de regarder que d'essayer de me souvenir :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
            private void LoadFile(string strPathList)
            {
                enc = Encoding.GetEncoding(1252);
                if (IsUtf8(strPathList))
                {
                    enc = Encoding.UTF8;
                }
    Bon, ben ce n'était pas UTF32 ...


    Si vous configurez correctement "Paramètres d'exception", vous avez automatiquement les tripes de l'exception (callstack, stacktrace, variables, threads, ...)
    Si j'ai bien suivi jusque là, le problème n'aurait pas dû se poser.

  8. #8
    Expert confirmé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 325
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2005
    Messages : 5 325
    Par défaut
    Cochez donc la case en regard de "System.Text.EncoderFallbackException", comme ça, vous verrez d'où vient la chaine de caractère qu'on n'arrive pas à "encoder".

    "IsUtf8", c'est peut-être le type de fonction qui peut déclencher de manière "intempestive" ce type d'exception, le compilateur l'indiquera dans la callStack.

    "string strPathList", pourquoi utiliser des strings et pas des types dédiés comme "System.IO.Path" ?

  9. #9
    Membre émérite
    Profil pro
    Développeur Web
    Inscrit en
    Février 2008
    Messages
    2 637
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Février 2008
    Messages : 2 637
    Par défaut
    Bon, je n'ai pas fini, mais je sais déjà que j'ai mal posé le problème : mon fichier de liste contient bel et bien des caractères exotiques, donc si jamais pour une raison pas encore élucidée il est lu en encodage 1252, c'est obligé que ça se passe mal.

    Me voilà donc avec du pain sur la planche :
    • revenir là-dessus pas à pas pour comprendre pourquoi un fichier UTF8 a été lu en 1252 (alors qu'il contient bien l'entête UTF8)
    • améliorer les messages d'erreur pour qu'au minimum je sache où ça se tient dans le code


    La fonction IsUtf8 a pourtant bien fait son boulot, le fichier commençait par (byte)0xEF, (byte)0xBB, (byte)0xBF, (byte)0x5B, alors il a dit vrai, sinon il aurait dit faux.


    À présent je vais parcourir mon code à la lumière de ça, ça va bien m'aider à m'en sortir. Et je vais veiller à ce que les messages d'erreur se ... présentent un peu plus, comme en fait je ... croyais l'avoir fait.

    Du côté de Git, pareil. Il y a encore un sacré taf, çà pour sûr, mais j'ai le début de la pelote : quand on est un peu désorienté avec Git sous Visual Studio, il faut attaquer ça avec Git Cmd, les messages sont beaucoup plus explicites.
    Bien sûr ça n'empêche pas que si on se met les deux pieds dans le même sabot on s'étale de tout son long, mais au moins on finit par comprendre pourquoi.

  10. #10
    Membre du Club
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Mai 2021
    Messages
    9
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Gard (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mai 2021
    Messages : 9
    Par défaut
    Attention :

    The Unicode Standard permits the BOM in UTF-8, but does not require or recommend its use.
    UTF-8 always has the same byte order, so its only use in UTF-8 is to signal at the start that the text stream is encoded in UTF-8, or that it was converted to UTF-8 from a stream that contained an optional BOM.

    Le BOM n'est pas obligatoire pour l'UTF8 en conséquence une fonction IsUTF8 n'as pas vraiment de sens ...
    Le classico : tes fichiers ne serais t-il pas en UTF8 mais sans le BOM ce qui fait qu'as un moment dans ton code tu utilise un Encoding 1252 car tu t'appuie sur ta fonction IsUTF8 pour déterminer l'encodage (genre c'est pas utf8 alors ces windows-1252).

Discussions similaires

  1. Erreur un peu bizarre
    Par trecks dans le forum C++
    Réponses: 4
    Dernier message: 06/11/2007, 10h25
  2. message d'erreur:Trop peu de paramètres
    Par karinal dans le forum Requêtes et SQL.
    Réponses: 5
    Dernier message: 03/09/2007, 20h13
  3. [erreur] trop peu de paramètres
    Par sempire dans le forum Access
    Réponses: 8
    Dernier message: 05/06/2006, 16h45
  4. erreur :Trop peu de paramètres, C'est koi??
    Par nickg dans le forum ASP
    Réponses: 18
    Dernier message: 06/01/2006, 16h59
  5. erreur trop peu de paramétre. un attendu ??
    Par Amandine62 dans le forum ASP
    Réponses: 3
    Dernier message: 25/01/2005, 16h00

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo