Pourquoi les nouveaux programmeurs semblent-ils ignorer les messages d'erreur du compilateur / messages d'exception d'exécution? [fermé]

Je pense que nous l'avons tous vu. Les débutants posent des questions sur Stack Overflow qui suivent le plan de base ...

J'essaye de faire (description très vague de l'objectif) mais ça ne marche pas / j'obtiens une erreur / exception. Aidez-moi!

N'est-il pas bizarre que tant d'entre eux semblent considérer qu'il n'est pas nécessaire de coller le message d'erreur?

Je me demande quelle est la psychologie de cela. Quels sont les messages d'erreur qui font que les gens supposent initialement qu'ils sont inutiles et ne méritent pas qu'on y prête attention?

La réponse que je cherche n'est pas «ils ne comprennent pas le message d'erreur». Cela n'explique pas pourquoi ils n'envisageraient pas de le dire à quelqu'un d'autre qui pourrait le comprendre.

Je pense que la vraie raison est que les utilisateurs d'ordinateurs ordinaires, même s'ils doivent devenir programmeurs, sont conditionnés à croire qu'ils ne peuvent rien faire contre les erreurs. Penses-y. Que font les types non programmeurs lorsqu'ils rencontrent un message d'erreur cryptique *? Ils peuvent le lire, mais neuf fois sur dix, ils vont simplement le rejeter et réessayer. Ce n'est qu'en cas d'échec constant qu'ils le rechercheront.

Par conséquent, lorsqu'ils commencent à apprendre à programmer, les gens ne réalisent pas immédiatement que l'erreur qu'ils obtiennent contient des informations utiles sur la façon de la corriger; et oui, bien que les erreurs du compilateur puissent être presque illisibles même pour le professionnel qualifié (je vous regarde, métaprogrammation du modèle C ++), au moins elles fournissent un point de départ général, et une fois que vous avez vu la même erreur plusieurs fois , vous saurez toujours ce que vous avez fait pour le provoquer.

* Honnêtement, cependant, la plupart des messages d'erreur ressemblent à Joe Average comme "Erreur X2412: Impossible d'établir un dongledash interplateforme frobnicatoire: veuillez vérifier les paramètres de bandersnatch ou contacter votre administrateur système."

Je pense que si c'est un vrai débutant, il y a de fortes chances qu'ils ne sachent pas du tout qu'il y a un message d'erreur. Ils savent seulement que cela ne fonctionne pas et qu'il y a une erreur. Par exemple, dans Visual studio, ils peuvent ne pas voir cette partie de l'écran.

Fondamentalement, ils ne savent pas quelle partie des informations dont ils disposent est utile pour comprendre quel est le problème. S'ils le faisaient, il y aurait de meilleures chances qu'ils puissent le réparer eux-mêmes et ne pas poser de questions à ce sujet en premier lieu.

Je pense que poser des questions et dépanner est une compétence qui doit être apprise, et pour les développeurs professionnels, c'est une compétence importante qui n'est tout simplement pas enseignée assez souvent.

Tout comme le code que vous écrivez lorsque vous commencez dans cette profession va être horrible par rapport au code que vous écrivez aujourd'hui, les questions que vous poserez seront terribles par rapport à la façon dont vous les posez aujourd'hui.

Lorsque vous commencez, il est facile d'être submergé par toutes les informations que vous apprenez et lorsque les choses ne vont pas se planifier, il est difficile de savoir quelles informations sont pertinentes et lesquelles ne le sont pas. C'est une grande partie de la raison pour laquelle les débutants ne peuvent pas résoudre le problème eux-mêmes en premier lieu!

Cela s'applique davantage à IRC qu'aux sites Web en ligne tels que Stack Overflow, ce qui est beaucoup plus rare.

Je pense que le raisonnement derrière cela est que les gens se sentent mieux s'ils savent qu'une personne en particulier s'intéresse à leur problème et est prête à les aider. Ils commencent donc par dire qu'ils ont un problème, mais ils n'entrent pas dans les détails jusqu'à ce que quelqu'un le leur demande, car ils ont peur qu'autrement, ils n'obtiennent pas de réponse de toute façon.

Parfois (pas dans le cas d'erreurs de compilation), ce comportement est en fait logique. Si j'ai un gros problème compliqué, je m'assurerai que quelqu'un écoute d'abord avant d'écrire une longue explication que personne ne lira.

Parce que les erreurs / exceptions du compilateur nécessitent que vous sachiez ce que vous faites mal pour y remédier. Ils sont destinés aux programmeurs qui négligent des choses, pas aux personnes qui ne les comprennent pas.

Ce ne sont pas toujours les plus évidents. Une erreur comme "inattendu si" n'est pas si intuitive. "Mais si ça devait être là" est la réponse d'un débutant. Un programmeur plus expérimenté sait que cela signifie qu'il a oublié le point-virgule sur la ligne précédente .

Je ne pense pas que ce ne soit que des débutants. J'ai des collègues avec des années d'expérience qui semblent ne regarder le numéro de ligne que lorsqu'ils obtiennent une erreur de compilation, puis essayer de comprendre le reste eux-mêmes (souvent en essayant le vaudou comme "ajoutons des parenthèses" ou "cassons ça) en deux déclarations ").

Je soupçonne que cela vient du fait que je n'ai pas vraiment une compréhension profonde des règles de la langue, de sorte que la description généralement dense de l'erreur n'a pas beaucoup de sens. expression must be a modifiable lvaluesemble être une information assez inutile si vous ne savez vraiment pas ce qu'est une valeur .

Quels sont les messages d'erreur qui font que les gens supposent initialement qu'ils sont inutiles et ne méritent pas qu'on y prête attention?

Eh bien, pour moi, c'était un jeune rempli de logiciels Windows 95 en panne avec des messages d'erreur complètement impénétrables qui se terminaient généralement par environ 150 lignes d'hexadécimaux.

Je revis la même expérience chaque fois que j'obtiens une belle trace de pile Java cryptique qui contiendra 40 lignes d'erreurs de compilateur et de mise en veille prolongée, et très bien cachées parmi elles est la référence réelle à l'endroit où se trouve l'erreur dans mon application.

La raison pour laquelle les gens ignorent les messages d'erreur et les traces de pile est souvent que les messages d'erreur et les traces de pile sont d'une complexité disproportionnée par rapport à la complexité du problème. Il n'y a aucune raison de vider 150 lignes de merde à travers mon écran lorsque je manque un point-virgule.

J'enseigne des cours sur Linux pour les administrateurs système juniors et la programmation avec PHP et Mysql. La majorité des étudiants sur PHP savent qu'il y a une erreur car ils voient le laid message à l'écran. Mais ils semblent incapables de le lire. Habituellement, je vais à leur écran quand ils me disent que quelque chose ne fonctionne pas, je lis l'erreur à l'écran, je leur dis de le lire, en soulignant le fichier et la ligne notés sur l'erreur et je leur dis de regarder là-bas. Ils corrigent l'erreur, mais lorsqu'une autre erreur apparaît, la même procédure s'applique ... soupir ...

Pour le cours Linux, parfois ils ne remarquent même pas l'erreur. Ils saisissent une commande, certaines lignes apparaissent à l'écran et continuent avec la commande suivante. Lorsque certaines commandes plus tard, ils remarquent enfin que quelque chose ne fonctionne pas et lèvent la main, je monte, fais défiler la console et pointe vers une commande qui s'est terminée avec une erreur en raison de mauvais paramètres ou autre. Leur visage: surprise. Donc, la partie facile pour mes étudiants Linux était de leur faire remarquer quand une erreur se produit, en utilisant une modification de l'invite bash pour la rendre différente lorsqu'une erreur apparaît, comme celle-ci . Maintenant, faites-leur lire le message d'erreur une fois qu'ils le voient, c'est une bataille différente (la même chose qu'avec les étudiants PHP) ...

Je pense qu'ils ne sont tout simplement pas habitués à penser aux codes d'erreur, et lorsqu'ils atteignent l'endroit où ils devraient les donner, ils ont déjà l'impression d'avoir expliqué le problème en profondeur, et sont donc encore moins susceptibles de s'arrêter et de se demander si ils devraient donner des informations supplémentaires.

Poser une question implique quelques étapes, et elles sont le plus logiquement organisées dans cet ordre:

1. vous devez décrire ce que vous faisiez
2. vous devez décrire comment vous faisiez cela
3. vous devez décrire ce qui s'est produit en cas d'échec (ou comment il a échoué)
4. vous devez fournir le rapport post mortem

Le rapport post mortem est l'endroit où le message d'erreur sera, et il est à la fin. Au moment où les débutants atteignent ce point, ils sont à la fin du défi mental d'expliquer leur problème et sont plus susceptibles de manquer quelque chose (pour un débutant, il y a un problème de surcharge d'informations). De plus, à ce stade, ils ont déjà l'impression d'avoir décrit tous les aspects du problème et ils ont des habitudes passées qui les empêchent de se souvenir des codes d'erreur: après tout, d'autres domaines de la vie n'ont pas de codes d'erreur, ils ne sont donc pas habitués à pensez-y.

Il se peut également que même s'ils se souviennent des codes d'erreur, ils semblent trop cryptiques pour être réellement utilisés. Qu'est-ce que l'erreur 034982? Est-ce que cela signifie vraiment quelque chose pour personne? Et cela ajoute-t-il vraiment quelque chose à cette description détaillée de ce que je faisais, comment je le faisais et comment cela a échoué? Certes, cette information se démarque d'elle-même.

Parce que pour la plupart des langues, la plupart des messages du compilateur / runtime n'ont aucun sens. (C ++ et Java en particulier, je vous regarde!) Obtenir les bonnes erreurs a tendance à être plutôt faible sur la liste des priorités d'un concepteur de langage. Faire en sorte que les choses fonctionnent bien est généralement une priorité plus importante, et la plupart du temps, ils ne se soucient pas de peaufiner les petits détails.

C'est l'une des raisons pour lesquelles j'aime travailler à Delphi. La langue entière est pleine d'attention aux petits détails, y compris les erreurs. Les messages du compilateur ont du sens. Les messages d'erreur d'exécution ont du sens. Les traces de pile ont un sens. C'est l'une des choses qui en fait, de loin, le langage de débogage le plus simple avec lequel j'ai jamais travaillé.