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_Name
attribut à 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 truncated
message 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 .