Quels sont les problèmes des développeurs avec des messages d'erreur utiles? [fermé]


29

Cela continue de m'étonner que, de nos jours, des produits qui ont des années d'utilisation à leur actif, construits par des équipes de professionnels, continuent à ce jour - ne fournissent pas de messages d'erreur utiles à l'utilisateur. Dans certains cas, l'ajout de quelques informations supplémentaires pourrait faire économiser des heures de travail à un utilisateur.

Un programme qui génère une erreur l'a générée pour une raison. Il a tout à sa disposition pour informer autant que possible l'utilisateur, pourquoi quelque chose a échoué. Et pourtant, il semble que la fourniture d'informations pour aider l'utilisateur est de faible priorité. Je pense que c'est un énorme échec.

Un exemple vient de SQL Server. Lorsque vous essayez de restaurer une base de données en cours d'utilisation, elle ne vous le permet pas. SQL Server sait quels processus et applications y accèdent. Pourquoi ne peut-il pas inclure des informations sur les processus qui utilisent la base de données? Je sais que tout le monde ne transmet pas d' Applicatio_Nameattribut à sa chaîne de connexion, mais même un indice sur la machine en question pourrait être utile.

Un autre candidat, également SQL Server (et mySQL) est le joli string or binary data would be truncatedmessage d'erreur et ses équivalents. La plupart du temps, une simple lecture de l'instruction SQL qui a été générée et le tableau montre quelle colonne est le coupable. Ce n'est pas toujours le cas, et si le moteur de base de données a détecté l'erreur, pourquoi ne peut-il pas nous faire gagner du temps et nous dire simplement de quelle fichue colonne il s'agissait? Sur cet exemple, vous pourriez faire valoir qu'il peut y avoir un impact sur les performances de le vérifier et que cela gênerait le rédacteur. Très bien, je vais acheter ça. Que diriez-vous, une fois que le moteur de base de données sait qu'il y a une erreur, il effectue une comparaison rapide après coup, entre les valeurs qui devaient être stockées et les longueurs de colonne. Affichez ensuite cela à l'utilisateur.

Les horribles adaptateurs de table d'ASP.NET sont également coupables. Les requêtes peuvent être exécutées et on peut recevoir un message d'erreur indiquant qu'une contrainte quelque part est violée. Merci pour ça. Il est temps de comparer mon modèle de données avec la base de données, car les développeurs sont trop paresseux pour fournir même un numéro de ligne ou des exemples de données. (Pour mémoire, je n'utiliserais jamais cette méthode d'accès aux données par choix , c'est juste un projet dont j'ai hérité!).

Chaque fois que je lève une exception de mon code C # ou C ++, je fournis tout ce que j'ai à la disposition de l'utilisateur. La décision a été prise de le jeter, donc plus je peux donner d'informations, mieux c'est. Pourquoi ma fonction a-t-elle levé une exception? Qu'est-ce qui a été adopté et qu'est-ce qui était attendu? Il me faut juste un peu plus de temps pour mettre quelque chose de significatif dans le corps d'un message d'exception. Enfer, cela ne fait que m'aider pendant mon développement, car je sais que mon code jette des choses qui ont du sens.

On pourrait faire valoir que les messages d'exception compliqués ne devraient pas être affichés pour l'utilisateur. Bien que je ne sois pas d'accord avec cela, c'est un argument qui peut facilement être apaisé en ayant un niveau de verbosité différent selon votre build. Même dans ce cas, les utilisateurs d'ASP.NET et de SQL Server ne sont pas vos utilisateurs habituels et préféreraient quelque chose de plein de verbosité et d'informations délicieuses, car ils peuvent retrouver leurs problèmes plus rapidement.

Pourquoi les développeurs pensent qu'il est acceptable, de nos jours, de fournir la quantité minimale d'informations lorsqu'une erreur se produit?

Il est 2011 les gars, venez sur .


11
Wow, c'est tout à fait une diatribe.
George Marian

3
@George, pouvez-vous dire que je viens de passer un long moment à rechercher quelque chose qui aurait vraiment pu être résolu plus rapidement en raison d'une erreur appropriée? :)
Moo-Juice

4
Je suggère des respirations profondes, peut-être du yoga et de la méditation. :) (Cela dit, je sais exactement ce que vous ressentez.)
George Marian

2
+1 - "les données de chaîne ou binaires seraient tronquées" me rend toujours fou!
k25

Réponses:


22

Bien qu'il existe de nombreux exemples de mauvais messages d'erreur qui ne devraient tout simplement pas l'être, vous devez garder à l'esprit qu'il n'est pas toujours possible de fournir les informations que vous souhaitez voir.

Il y a aussi le souci d'exposer trop d'informations, ce qui peut conduire les développeurs à des erreurs de prudence. (Je vous promets que le jeu de mots n'était pas prévu, mais je ne le retire pas maintenant que je l'ai remarqué.)

Parfois, il y a aussi le fait qu'un message d'erreur complexe est inutile pour l'utilisateur final. Faire face à la surcharge d'informations n'est pas nécessairement une bonne approche pour les messages d'erreur. (Cela peut être mieux enregistré pour la journalisation.)


+1 Je n'ai même pas pensé à la surcharge d'informations.
Ryan Hayes

J'ai expliqué dans mon article que je peux comprendre pourquoi certains estiment que la verbosité envers un utilisateur final pourrait leur être inutile. Mais dites-vous que les utilisateurs finaux d'une API (les adaptateurs ag ASP.NET) ou d'un moteur de base de données (SQL-Server) ne veulent pas d' erreurs verbeuses? Quelque chose qui nous sauverait potentiellement des heures de temps perdu? Au fait, j'ai aimé le jeu de mots :)
Moo-Juice

1
@George, également en ce qui concerne la surcharge d'informations et son utilité pour l'utilisateur final, encore une fois, je peux voir un cas pour ne pas lancer une trace de pile complète à l'utilisateur d'un traitement de texte, de peur qu'ils n'aient un moment de pantalon brun et je pense qu'ils ont supprimé Internet. Cependant, vous avez fourni une excellente alternative avec des informations complexes dans le fichier journal. Il ne reste plus qu'à ajouter ce message For further information, see log20111701.txt. Ce serait un pas dans la bonne direction.
Moo-Juice

2
@moo En fin de compte, ce que je dis, c'est qu'il est facile de critiquer. (Je sais, je le fais souvent.) Cependant, j'essaie de garder à l'esprit qu'il n'est pas nécessairement facile de dire combien d'informations vous devez inclure dans un message d'erreur. Il y a de nombreuses fois où j'ai dû sauvegarder et produire des informations plus détaillées que ce à quoi je m'attendais lors du débogage. De plus, il y a de nombreuses fois où un message d'erreur n'était pas aussi utile que je l'avais prévu lors de sa création.
George Marian

1
@moo Le nœud du problème est qu'il n'est pas toujours évident de savoir combien d'informations sont utiles. Les exemples que vous donnez semblent assez évidents. Cependant, il n'est pas facile d'étendre cela au cas général.
George Marian du

21

Les développeurs ne sont pas les bonnes personnes pour écrire des messages d'erreur.

Ils voient l'application sous le mauvais angle. Ils sont extrêmement conscients de ce qui s'est mal passé dans le code, mais n'abordent souvent pas le logiciel du point de vue de la tâche à accomplir. Par conséquent, les informations importantes pour le développeur ne sont pas nécessairement des informations importantes pour l'utilisateur.


+1 Pour de nombreux types d'erreurs Framework / API, le problème vient en partie du fait que le développeur de la bibliothèque ne peut pas connaître le contexte. Cela dit, OP semble surtout préoccupé par les types de messages d'erreur "quelque chose ne va pas, mais je ne vais pas vous dire où même si je connais". Je suppose que c'est la sécurité, non?
MIA

8

La vue caritative:

  • Le développeur a travaillé en étroite collaboration avec le code et a eu du mal à comprendre quelqu'un qui ne comprenait pas son fonctionnement. En conséquence, ils pensent que les messages d'erreur sont corrects, ils n'ont tout simplement pas un bon cadre de référence pour les juger.

  • Les messages d'erreur intelligents sont en fait difficiles à faire. Non seulement les écrire, mais vous devez trouver tout ce qui pourrait mal tourner, évaluer la probabilité et fournir des informations utiles (qui varient presque certainement en fonction du contexte) à la personne qui lit le message pour lui permettre de le corriger.

  • Pour la plupart des applications, il est difficile de faire une bonne affaire pour le temps de faire ce genre de chose ainsi que le prochain développeur le voudrait vraiment car les erreurs ne se produisent pas souvent. De plus, si vous aviez ce temps supplémentaire, ne devriez-vous pas le consacrer à arrêter les erreurs plutôt qu'à en rendre compte?

La vue non charitable:

  • Les messages d'erreur et la gestion des erreurs sont ennuyeux, il y a des choses beaucoup plus intéressantes à travailler et mon patron est sur le dos pour la prochaine chose. Je comprends ce code, tout ira bien, le gars suivant le finira et je serai d'ici d'ici donc ce n'est pas mon problème.

La réalité se situe probablement quelque part entre les deux, bien que mon expérience me dise en fait que c'est beaucoup plus ancien que tardif - en fait, c'est en fait assez difficile et demande beaucoup d'efforts pour faire face à quelque chose qui ne se produira probablement pas.


Je comprends d'où vous venez dans de nombreux cas d'utilisateurs finaux. Cependant, les cas que j'ai décrits dans mon article d'origine peuvent se produire fréquemment lors de l'écriture de code sur des bases de données. En ce qui concerne les applications d'utilisateur final telles qu'un traitement de texte ou un jeu d'ordinateur, les erreurs ne devraient généralement pas se produire à moins qu'il ne se passe quelque chose de mal , et même alors, l'erreur pourrait ne rien signifier pour l'utilisateur final ( Process Handle Raped By Spawned Injector, Quitting SYstem..... utilisateur: "wtf ai-je fait?`). Mais dans le cas de SQL Server / ASP.NET, je pense que plus d'efforts auraient pu être faits :)
Moo-Juice

@ Moo-Juice - Je pense que cela se résume à la chose "les messages d'erreur sont difficiles". Sous le capot, ce qui est réellement jeté dans la base de données une fois que l'optimiseur a fait sa chose n'a qu'une ressemblance passagère avec ce que vous lui avez lancé. Identifier l'erreur est une chose, retracer ce qui est arrivé à ce que vous avez passé en est une autre entièrement et absolument pas triviale.
Jon Hopkins

certains cas peuvent ne pas être triviaux. J'ai un simple bout de code quelque part qui capture l' string/binary dataerreur qui extrait toutes les informations de colonne de ladite table, examine les valeurs passées et montre quelles colonnes auraient été en violation. C'était trivial. Peut-être que je rique trop parce que mes exemples de cas sont triviaux, mais je comprends parfaitement que ce n'est pas toujours le cas. La façon dont nous empêchons les injecteurs engendrés de violer pourrait bien être difficile :)
Moo-Juice

6

Malheureusement, des messages d'erreur plus utiles coûtent du temps au développeur, ce qui équivaut à l'argent de l'entreprise. Les produits sont assez chers à construire tels quels. Oui, ce serait génial d'avoir des messages d'erreur plus utiles, et je suis d'accord qu'il devrait y en avoir plus utiles. Cependant, c'est juste une réalité de la vie que lorsque vous êtes sous un délai, et que l'argent est en jeu, vous devez couper quelque chose. «Des messages d'erreur plus jolis», comme les gestionnaires peuvent le voir, seront probablement la première chose à faire.


Ah, oui, bon point. Cette préoccupation toujours présente du coût.
George Marian

Je peux concéder une perspective de coût (et bon sang, cela ne signifie pas que je dois l' aimer ). Je ne peux pas parler du point de vue des développeurs de SQL Server ou ASP.NET, mais je ne sais qu'il ne faut pas que beaucoup d' efforts supplémentaires pour fournir un nom de colonne. J'avoue que, pour mon exemple simple, cela pourrait être résolu en une heure. Ensuite, il y a les 1000 autres erreurs qui pourraient être générées. Mais ils pourraient au moins commencer par les plus courants :)
Moo-Juice

bien sûr, je ne connais pas les composants internes de SQL Server - mais de manière générale, le plus souvent, vous n'avez pas ces informations à portée de main au moment où la situation d'erreur est détectée. Une formulation comme "chaîne ou données binaires" vous montre très clairement qu'au site d'erreur, il n'est même pas clair si la valeur tronquée était une chaîne ou un nombre ...
Ichthyo

À un certain niveau, cela peut être valide, mais le même problème apparaît même dans de simples scripts Perl où simplement ajouter $! au message d'erreur serait extrêmement utile. Il est moins cher (en termes de temps du développeur) d'écrire 'die "$ path: $!"' Que d'écrire le 'die' totalement inutile 'Impossible d'ouvrir $ path "'
William Pursell

6

J'accepte que les messages d'erreur soient aussi précis que possible.

L'une des raisons des messages d'erreur génériques est probablement l'utilisation de codes d'erreur. Lorsque vous utilisez des exceptions, vous êtes libre de transmettre tout ce dont vous avez besoin dans le message d'erreur. En utilisant des codes retour, il n'y a pas de place pour encoder un nom de colonne. Peut-être que l'erreur est gérée par une fonction générique qui ne connaît pas le contexte et traduit simplement le code d'erreur en une chaîne.


c'est encore pire: bien que vous puissiez déclencher des erreurs à des points très spécifiques, afin de gérer les erreurs, vous êtes obligé de regrouper plusieurs possibilités dans une classe de situations et de les gérer avec une seule récupération. Cet acte de généralisation vous oblige fréquemment à supprimer encore plus d'informations rares sur le contexte.
Ichthyo

btw ... ce mécanisme conduit à toute une classe de messages d'erreur drôles - du type "Défaut grave -567 dans le module nain678: Aucune erreur détectée"
Ichthyo

4
  • Parfois, trop d'informations peuvent constituer un risque pour la sécurité; vous ne savez pas qui lit le message d'erreur
  • Parfois, l'opération qui a levé l'exception est si complexe qu'il est impossible d'obtenir un message significatif sans effets négatifs sur la vitesse / complexité du code

J'ai répondu à votre premier point permettant un changement de verbosité aux exceptions levées dans votre code. Votre deuxième point est sans objet étant donné qu'à ce stade, une erreur s'est produite et que la vitesse n'est plus un facteur décisif (à mon humble avis). Et si la production d'un message d'erreur détaillé nécessite un impact sur les performances AVANT de lever l'exception, je suis d'accord. Déplacez ce code vers APRÈS que l'exception ait été levée. Je ne vois aucun de ces points comme un argument valable contre les messages d'erreur appropriés :)
Moo-Juice

Certes, je suppose que vous pouvez rechercher les informations une fois que quelque chose s'est produit plutôt que de garder une trace de ce dont vous pourriez avoir besoin. Cependant, si vous êtes dans des boucles imbriquées, la capture des index / index peut être problématique.
StuperUser

-1 pour le premier point avec lequel je ne suis pas d'accord, +1 pour le deuxième point.
Jon Hopkins

1
@jon Comparez un message d'erreur générique pour les erreurs de connexion par rapport à des messages d'erreur plus spécifiques qui vous indiquent réellement ce qui s'est mal passé. par exemple "Nous n'avons pas pu trouver cette combinaison nom d'utilisateur / mot de passe" vs "Vous avez entré un mot de passe incorrect." / "Ce nom d'utilisateur n'existe pas." Il semble que je me souvienne d'une vulnérabilité dans ASP.NET où le message d'erreur était réellement utile pour casser des clés de chiffrement.
George Marian

@George - Je suis d'accord avec cet exemple mais je ne pense pas qu'il soit répandu. Une fois que vous avez été autorisé à accéder à une application, un certain niveau de risque disparaît, car vous pouvez supposer que la personne est (a) autorisée et (b) pourrait obtenir la majeure partie de ce qui est nécessaire de l'application réelle.
Jon Hopkins

3

De manière générale, vous devez considérer que toute erreur ou situation exceptionnelle est - exactement cela: exceptionnelle. Il recoupe la procédure planifiée et conçue. Il est incompatible avec la façon dont les choses devaient fonctionner. Si ce n'était pas le cas, il ne serait pas nécessaire de renflouer avec une erreur abandonnée.

Nous, les programmeurs, sommes formés pour prendre soin de l'autoprotection de cette procédure planifiée. Ainsi, nous incluons régulièrement des vérifications d'intégrité pour vérifier nos hypothèses. Lorsque ces vérifications de santé mentale échouent, nous savons simplement que le plan a échoué en quelque sorte ...

Votre demande - cela peut sembler du bon sens du point de vue de l'utilisateur - est impossible à satisfaire si vous considérez la réalité du fonctionnement d'un tel système. Vous demandez une déclaration ordonnée avec des informations bien organisées et appropriées ajoutées. De plus, vous demandez même que cette présentation se déroule d'une manière qui corresponde à la conception générale de l'application / manipulation. De toute évidence, cette information existe quelque part dans le système. Évidemment, il existe même là-bas de manière ordonnée et bien organisée (espérons-le). MAIS au moment où l'erreur se produit, personne n'a jamais prévu de rendre ces informations disponibles. Une erreur est toujours une perte de contrôle partielle.Cette perte de contrôle peut se produire à différents niveaux. Il se peut que le système se comporte au moment de l'exécution différemment que prévu. Mais il se pourrait aussi que la mise en œuvre effective se soit avérée beaucoup plus difficile et différente dans les détails alors prévus, et il n'y avait aucune disposition budgétaire pour gérer cette situation de manière satisfaisante. C'est aussi une perte de contrôle partielle.

Pour relier cela à l'exemple concret que vous avez donné: si, au moment de l'erreur, le nom et le type de la colonne du tableau étaient connus, ainsi que la longueur de l'espace requis, il n'y aurait aucune raison de faire une erreur, non? Nous pourrions simplement corriger la situation et procéder comme prévu. Le fait même que nous soyons obligés de soulever une erreur nous montre que les choses ont mal tourné. Le fait même que ces informations ne soient pas à portée de main est l'exception .

Ce que j'écris ici peut sembler évident et simple bon sens. Mais en réalité, il est extrêmement difficile à saisir. Nous essayons constamment de le comprendre en appliquant des catégories morales - comme il doit y avoir un coupable, il doit y avoir une mauvaise personne paresseuse qui ne se soucie pas du pauvre utilisateur, il doit y avoir des hommes d'affaires cupides qui ont fait un moyen de calcul bon marché. Tout cela est complètement hors de propos

La possibilité d'une perte de contrôle découle du fait même que nous faisons les choses de manière planifiée et ordonnée .


Je dois être en désaccord. Il sait que quelque chose ne va pas (il ne peut pas effectuer l'opération). Savoir que quelque chose ne va pas indique la raison pour laquelle c'est mal. Cette chaîne est trop grande pour cette colonne (ou une colonne de cette table). Ça pourrait me le dire, sans trop de travail. C'est un putain de moteur de base de données d'entreprise. Il sait . Mais il ne transmet pas cette information. Étant donné que le programmeur peut écrire une requête à exécuter après coup pour le découvrir, le moteur de base de données pourrait faire de même. Ce ne sont pas des facettes secrètes non documentées. Juste un message d'erreur merdique :)
Moo-Juice

heh ... vous devriez baser votre argument sur la logique, pas sur la pensée de vœux. Depuis quand un ordinateur sait-il quelque chose? Ce n'est pas du cinéma hollywoodien. Un programme est une configuration rigide et pré-arrangée, et lorsque vos hypothèses sont brisées, vous avez perdu le contrôle. Est-ce vraiment si difficile à saisir? Un ordinateur ne comprend pas le programme, et donc il ne peut pas comprendre quand ça va mal. Presque toujours, lorsque des vérifications de cohérence se déclenchent, l'exécution a déjà commencé par des milliers d'instructions et personne ne sait quelles données ont déjà été corrompues. Tout ce que vous pouvez faire est de limiter les dégâts
Ichthyo

2

Je travaille en tant qu'ingénieur de support pour une société de logiciels et nous voyons souvent des messages d'erreur qui sont nouveaux pour nous. Souvent, lorsque je les renvoie à notre équipe de développement, ils doivent rechercher le message dans la source de l'application.

Il me semble que même s'il n'était pas présenté aux utilisateurs, cela nous ferait gagner beaucoup de temps si l'équipe de développement ajoutait une note à un document d'index de message d'erreur ou à une base de données chaque fois qu'elle en ajoutait une nouvelle, cela la rendrait beaucoup plus rapide pour nous de trouver la cause des problèmes des clients et de leur faire gagner du temps aussi ...


1
désolé, c'est assez peu pratique. Qui serait responsable de la gestion de ce document d'index, de sa précision. Comme toute documentation écrite distincte du code, elle serait obsolète et commencerait à obtenir une source de nouvelles erreurs au moment même où elle est écrite.
Ichthyo

Au contraire, c'est le genre de chose qu'un script pourrait extraire du code source, si chaque erreur avait un numéro unique, et la description de chacune était également dans le code sous la forme d'un commentaire (spécialement formaté) ou en tant que chaîne. Le document serait donc généré automatiquement avec chaque build. Le message extrait pourrait alors être un peu plus détaillé que tout ce que vous voudriez que l'utilisateur final voie. Pas une mauvaise idée!
Jeanne Pindar

vous n'avez pas besoin d'un script pour cela - de nombreux systèmes d'exécution peuvent enregistrer le numéro de ligne ou des informations similaires. Malheureusement, cela ne résout pas le problème d'origine, car de cette façon, nous savons simplement où une exception a été détectée, mais nous ne savons pas ce qui s'est passé . Découvrir ce dernier s'appelle le débogage - en pratique, c'est une tâche plus ou moins fastidieuse et exigeante en travail effectuée par les humains.
Ichthyo

Je suis avec @Jeanne - assez simple pour incorporer dans le code ou pour avoir un index central dans le code avec le code d'erreur et leur interprétation. Une fois que vous savez où une exception a été détectée, cela peut être suffisant pour vous dire qu'il y a un problème avec l'environnement quelque part plutôt que quelque chose dans le code qui doit être recherché.
glenatron

2

Le problème que vous voyez là est en fait l'un des effets secondaires d'une bonne encapsulation et de la dissimulation d'informations.

Les systèmes modernes sont extrêmement compliqués. Il y a peu de chances que le développeur moyen soit capable de tenir, dans sa tête, un modèle mental de l'ensemble du système de l'interface utilisateur au binaire brut pendant qu'il code une tâche particulière.

Ainsi, alors qu'un développeur est assis et code, disons, le bit qui restaure un fichier de base de données, son modèle mental est entièrement rempli des bits entourant l'acte de restauration d'un fichier de base de données. Il doit (et je suppose, je n'ai pas écrit ce code) lire un fichier, vérifier les propriétés, lire les versions, sauvegarder les données existantes, choisir une stratégie de fusion / écrasement, etc. Très probablement, s'il y a même un passage considération à l'interface utilisateur, son dans la chaîne d'erreur qu'il écrit dans un gestionnaire d'exceptions. Quelque chose comme:

catch (IOException error)
{
//File is in use
throw new GenericExceptionParsedByTheUIThread("File is in use.");
}

Dans cet exemple, les informations utiles que vous demandez en termes de processus qui pourraient utiliser le fichier, ou même d'autres threads dans la base de données, sont complètement hors de portée (par programme). Il peut y avoir des centaines de classes qui traitent des fichiers DB; importer dans ces classes des informations sur tous les autres processus utilisant les fichiers, ou des fonctionnalités pour accéder au système de fichiers et regarder les autres processus en cours d'exécution (en supposant que ces processus sont même sur CET ordinateur) entraîneraient ce qu'on appelle une abstraction qui fuit ; il y a un coût direct de productivité.

C'est ainsi que ces types d'erreurs peuvent persister dans les temps modernes. De toute évidence, ils POURRAIENT tous être corrigés; mais dans de nombreux cas, il y a beaucoup plus de frais généraux que l'on pourrait penser (dans ce cas par exemple, vous devrez peut-être que cette fonction traverse l'énumération des connexions et des partages réseau pour voir si une machine distante utilise ce fichier de base de données pour certains raison) et le coût est loin d’être négligeable.


@GWLlosa, c'est une excellente réponse et une que je n'avais pas envisagée. Cela dit (et je ne peux pas fournir d'exemple de code complet ici), lorsque j'obtiens cette exception IOException, avant de lancer mon GenericException, je pourrais 1) Demander au Processessous - système une liste de processus. 2) Demandez à chaque processus quelle base de données il utilise. 3) Faites correspondre le processus avec la base de données affectée à celle que j'essaie d'écraser, 4) lancez une DatabaseInUse(dbName, processName, applicationNameexception. :)
Moo-Juice

1
Certainement possible; mais le code pour faire correspondre la base de données au processus (en particulier sur le réseau) peut être lui-même compliqué / lent / sujet aux erreurs, ce qui pourrait entraîner une certaine frustration supplémentaire ("J'essaie simplement de restaurer le local (* #% ^! % file !!!! POURQUOI JE VEUX QUE LES PARTAGES DU RÉSEAU NE SONT PAS ACCESSIBLES! ??!?! ")
GWLlosa

1
@ Moo-Juice: ce que vous proposez semble assez naïf. Dans un environnement multithread massif comme une base de données, vous ne pouvez pas simplement vous adresser à un service global pour obtenir une liste de "tous les xyz". Même pour parler à un autre service dans un autre thread, vous avez besoin d'un verrou, ce qui pourrait conduire à un blocage de l'ensemble du système au pire, cela pourrait corrompre d'autres données ou au moins cela pourrait provoquer des erreurs supplémentaires, que vous devez également gérer. ....
Ichthyo

1
Cet exemple est en effet très instructif: généralement dans un tel gestionnaire de capture, vous ne pouvez même pas dire avec certitude quelle partie du bloc try a échoué (généralement, plusieurs parties peuvent provoquer une exception IOException). En plus de cela, il est très probable qu'à cet emplacement, vous ne puissiez pas dire le nom du fichier, de peur de savoir quelle table logique correspond à ce fichier.
Ichthyo

@Ichthyo, pas d'offense mais je ne pense pas que ce soit naïf du tout. Je ne demande pas au moteur de base de données de verrouiller le système pour me dire quel processus a encore une poignée sur une base de données. Je ne lui demande pas d'arrêter toute l'entreprise. S'il doit me donner une réponse simple, cela montre en premier lieu un défaut fondamental de conception du serveur de base de données. N'oubliez pas, il est censé être conçu pour rendre les informations pertinentes de la manière la plus rapide possible. Pour lui poser la question "qui?" ne devrait vraiment pas être aussi naïf que vous le dites :)
Moo-Juice

2

Mon préféré était (à la fin des années 70) le compilateur Univac Fortran IV, lors de la lecture des non-chiffres, fidèlement annoncé

L'interprétation de données dénuées de sens a été tentée


+1, absolument fantastique! C'est le genre d'erreur qui vous donne juste envie d'abandonner et d'aller élever des poulets aux Fidji.
Moo-Juice

en effet, ce message d'erreur est précis à 100% - si vous voulez un message plus convivial avec plus de conetxt, vous devez intégrer des hypothèses et des heuristiques; de cette façon, vous ajoutez la possibilité de messages d'erreur trompeurs ..
Ichthyo

0

Je crois que la majorité des messages d'erreur sont en fait des instructions de code de débogage glorifiées (auto) orientées programmeur.

Écrire des messages d'erreur orientés utilisateur signifie savoir qui est votre utilisateur et anticiper ce qu'il voudra savoir. Alors qu'il est en train d'écrire du code, un développeur est plus apte à écrire un message d'erreur utile pour lui-même, soit pour déboguer le code qu'il écrit actuellement, soit utile pour les cas d'utilisation connus ou prédominants.

Passer de l'écriture de code à la conception d'une partie textuelle de l'interface utilisateur (ou de l'expérience utilisateur) est un changement de contexte. Dans les applications volumineuses, telles que les applications multilingues qui pourraient signifier qu'elles sont transférées à une autre personne ou équipe (interface utilisateur, traduction) plutôt que entièrement gérées par le développeur, donc à moins que le développeur n'explique soigneusement le contexte du message, des détails importants peuvent être facilement perdu.

Bien sûr, la vérification et la vérification de la gestion des erreurs sont souvent considérées comme une priorité faible, tant que les erreurs et les exceptions sont gérées (c'est-à-dire interceptées), peu d'importance y est accordée. C'est un endroit mentalement ingrat de la base de code pour les développeurs ou QA à évaluer, car les conditions d'erreur ont souvent une connotation négative (c'est-à-dire une erreur ou un échec) qui leur est associée.


0

Je pense que la raison en est que le rapport / traitement des erreurs se fait toujours après coup . Même lorsqu'ils ne sont pas entièrement réfléchis, ils sont pour la plupart des citoyens de seconde classe dans la conception globale.

Les logiciels modernes se composent généralement de plusieurs couches. Lorsque votre logique de rapport d'erreurs est établie à la hâte sans trop réfléchir, il est souvent difficile de rassembler toutes les informations nécessaires pour présenter des messages d'erreur utiles.

Par exemple, l'erreur est interceptée dans le serveur principal, mais elle a besoin de certaines informations des couches supérieures pour composer un message d'erreur complet. La plupart des bons messages d'erreur nécessitent des informations provenant de presque toutes les couches (pour nous donner une vue complète de ce qui s'est passé dans le système). Le message d'erreur idéal ressemblerait à "OK, nous avons d'abord reçu une chaîne, puis elle est passée à travers l'analyseur qui a donné quelque chose de drôle, vous voudrez peut-être y regarder. Quoi qu'il en soit, la chose a été transmise plus bas ..."

Le faire nécessiterait souvent un couplage inutile si le mécanisme de rapport d'erreurs n'était pas un citoyen de première classe pendant la phase de conception. Je suppose que la plupart des gens trouvent que trop de travail à faire pour quelque chose qui ne semble pas impressionnant (qui aime dire "Voir? Mon programme s'est écrasé et le message d'erreur est utile!").

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.