Fournir des solutions suggérées dans les messages d'erreur

Question

Les

outils et logiciels de développement ne fournissent généralement pas les suggestions de solutions dans les messages d'erreur . Cela a du sens pour les compilateurs, car ils sont censés dire avec précision ce qui ne va pas.

Il existe des outils "Lint" permettant de formuler des suggestions, mais, autant que je sache, peu de développeurs utilisent les outils de la charpie régulièrement, voire pas du tout.

Il existe un grand ensemble de logiciels destinés aux développeurs qui auraient intérêt à avoir une "solution suggérée" " en partie aux messages d'erreur . C’est l’une des fonctionnalités remarquables des IDE comme Eclipse. Mais les logiciels tels que les frameworks d'applications Web, les bibliothèques standard / populaires, etc. ne disposent pas de cette fonctionnalité utile.

Est-ce quelque chose qui manque simplement de conception conviviale (on peut considérer cela comme inutile, étant donné que Google est si bon) ou y a-t-il une bonne raison à cela? Les compilateurs, les frameworks et les plates-formes que vous utilisez fournissent-ils des messages d'erreur avec des suggestions de solutions, le cas échéant? Pourquoi pas?

Answer 1

La principale chose que je veux d’une erreur de compilation ou d’exécution est le contexte - où cela s’est-il passé et où a-t-il été appelé quand cela a échoué.

Je pense que la plupart des compilateurs et des runtimes modernes (Java, Ruby, Go) font un travail correct, avec des numéros de ligne et des traces de pile, vous pouvez trouver la plupart des bugs. Même si les options Javascript deviennent bonnes, cela bat certainement le bon vieux & alert; alert () " approche de débogage.

N'est-il pas assez juste de laisser les solutions suggérées aux IDE?

Mais je suis d'accord pour dire que j'ai vu des frameworks / bibliothèques très rares avec des messages d'erreur et "NullPointerException à la ligne 264". profondément dans une bibliothèque tierce où vous n'avez pas le code source vous dit très près de rien.

S'il s'agit d'un problème, je pense qu'il est principalement limité aux bibliothèques tierces. La " bonne raison " est sans doute qu’il a été développé à la hâte pendant le temps libre de quelqu'un et que celui-ci n'a pas placé de messages d'erreur significatifs très haut sur la liste des priorités.

Answer 2

Que voulez-vous voir?

Error: Null Pointer Exception (suggested solution: Set the object to something).

Je veux dire, ce n'est pas le travail des rédacteurs d'erreur de vous éduquer. Je préfère les messages d'erreur simples qui indiquent le problème exact. Je peux donc déterminer moi-même ce qui le cause cette fois-ci. Pour moi, cela relève certainement du domaine des outils tiers; peut-être que les compilateurs pourraient leur fournir un contexte détaillé, pour faire leur analyse, mais ce n’est pas quelque chose que je trouverais vraiment utile.

Answer 3

La solution à une erreur est difficile à résoudre. Il y a tellement de possibilités et, comme @silky l'a souligné, certaines ne peuvent tout simplement pas être diagnostiquées.

Les

Avertissements sont une autre bête. Dans de nombreuses situations, les compilateurs modernes utilisent ces mots pour dire "Je pense que vous vouliez dire X quand vous avez dit Y; vous voudrez peut-être vérifier cela. "

Answer 4

Un langage de programmation peut être le nec plus ultra en termes de flexibilité en termes d’interface utilisateur. Vous pouvez faire que l'ordinateur fasse tout ce que vous voulez. Le revers de la médaille est que si vous tapez au moins un caractère, il n’aura peut-être aucune idée sur quel axe votre erreur a été commise, ni à quel endroit.

Les systèmes moins flexibles offrent plus de possibilités d’offrir des solutions aux problèmes. Si vous tapez (a b c) dans votre compilateur Lisp et qu'il ne sait pas ce que c'est, il est si proche de tant de lignes de code valides qu'il ne peut pas suggérer exactement un correctif unique. Si vous avez mal orthographié & "Division IDENTIFICATION" au début de votre programme COBOL, il est relativement facile pour le compilateur de détecter l'erreur et de vous aider. La plupart des autres langues se situent entre ces deux extrêmes.

Les programmeurs ont tendance, au cours de leur carrière, à passer de langages moins puissants et plus structurés à des langages plus puissants et plus flexibles. (Du moins, c’est ce que j’ai vu se produire avant que Javascript ne devienne une langue aussi novice que populaire.) Cela signifie que leur discipline s’améliore au point de leur permettre d’utiliser des outils qui offrent du pouvoir au détriment de savoir quoi faire. Les environnements que j’ai utilisés et qui me disent ce qu’il faut réparer sont généralement ceux que je n'aime pas utiliser.

Ce n'est pas différent de tout autre art. Regardez des musiciens ou des peintres ou des artistes martiaux ou des acteurs ou des écrivains ou des chefs ou même des gens qui apprennent à parler espagnol: quand ils sont jeunes et inexpérimentés, ils sont placés dans un système avec beaucoup de structure et s'ils se trompent quelqu'un peut facilement les corriger. À mesure qu'ils deviennent plus qualifiés, ils ont besoin et veulent de moins en moins de soutien. Une fois devenus experts, ils n'ont plus besoin de soutien, mais le revers de la médaille est que vous ne pouvez pas dire aussi facilement ce qui est juste ou faux. Si votre enfant colore au-delà des lignes, vous pouvez expliquer le problème, mais si Picasso ou Pollock font un mauvais coup de pinceau, que diriez-vous? Ou si Philip Glass met une note hors de propos ou si Bruce Lee transforme son corps trop loin en coup de poing? Et qui voudrait travailler dans un art si limité que les choses profanes ne sont pas possibles? Les compilateurs COBOL existent toujours si quelqu'un le veut vraiment, mais beaucoup plus de gens paient de l'argent pour des peintures affreuses que des impressions magistrales couleur par numéro.

Plus directement, il existe un site, ErrorHelp (nee bug.gd), qui vous permet de saisir un message d'erreur et un résultat, mais plus ancien que SO, mais personne ne l'utilise . J'ai essayé. À moins que vous ne vous trouviez dans un contexte où il n’ya qu’une réponse possible, un dictionnaire simple qui pose problème au dictionnaire de solutions suggérées ne fonctionne pas et, par conséquent, c’est un échec total dans tous les champs de création.

Answer 5

La plupart des IDE ont leurs propres compilateurs. Cela leur permet de faire une compilation partielle, des refactorisations de code et de nombreuses autres astuces. Je trouve les messages d'erreur et les suggestions assez utiles. Ce n'est pas parce que le compilateur n'est pas appelé en ligne de commande que ce n'est pas un compilateur.

texte alt http://www.theeggeadventure.com /wikimedia/images/1/1f/Eclipse-error.png