Hm, je comprends pas bien. Pas du tout en fait :/

Je crois avoir compris : une application plante, et au lieu de remonter le bug pour que les dev corrigent, un utilisateur demande d'afficher un message d'erreur pour pouvoir ensuite refaire un rapport de bug grâce à ce message.

je suis loin d'être un connaisseur en Bd, et là j'ai du mal à saisir toutes les finesses de la chose :'(

Bah, justement, c'est ce que je pensais, mais l'utilisateur semble aussi avoir remonté le bug de façon assez claire, donc du coup ça me fait douter.

heu... t'es sûr?

Je peux me planter, le PEBKAC n'est pas très clair, je dois bien l'avouer... Mais du coup, j'ai l'impression qu'en écrivant ce rapport de bug, l'utilisateur a remonté le bug sans trop s'en rendre compte, et au lieu de demander de le corriger, il demande quelque chose à coté de la plaque. hum... Hum. ? des précisions ?

Danarmk a vu juste : l'application plante si des données manques dans la BDD, le client remonte le bug (jusque là ça va) sauf qu'au lieu de demander une correction il demande à ce qu'un message d'erreur soit affiché pour que l'utilisateur puisse signaler ... ce même bug aux équipes de dev. On a donc une non-correction et une jolie boucle infinie, le même problème sera remonté sans jamais être corrigé. J'espère que l'auteur n'a pas tenu compte de la suggestion très intelligente de ce client :D

Ce PEBKAC me laisse perplexe.

Personnellement, quand je doit traiter un ticket du genre "l'appli machin a planté, SQLCODE +100" et qu'il n'y a aucune autre info ni trace, je suis pris d'une soudaine envie de clôturer le ticket en "analyse impossible" sans chercher plus loin et de casser quelques doigts au gus qui a codée la gestion d'erreur.
Par contre, si j'ai une trace qui identifie la requête utilisée et indique les valeurs en entrée, là je peut travailler.

Tel que je comprend le rapport de bug cité, l'utilisateur demande de mettre des messages d'erreur pertinents au lieu de s'attendre à ce que le dév sorte une boule de cristal.
Il m'a l'air d'être super sympa cet utilisateur!

Si on retire "à la place" dans le message du client, ça a du sens. Si l'application plante (ce qu'elle ne devrait pas faire), elle devrait renvoyer l'erreur (pas dire qu'il y en a une, mais des détails à envoyer aux développeurs).

Bof, pour moi le client veut surtout que l'application ne plante pas soudainement sans info, et souhaite au moins que le problème ait un nom (à défaut d'une solution).
Pour moi ce n'est pas un PEBKAC, juste un utilisateur qui souhaite apporter (maladroitement certes, mais c'est pas son boulot) un début d'amélioration au problème.

pour moi il y a un petit PEBKAC. Si on fait une requête, on commence par faire un petit if pour vérifier qu'on à obtenu un résultat avant de lancer une bouche ou un traitement.

accessoirement ça permet aussi de caser un ELSE qui affichera un message disant qu'il n'y a pas de données à traiter

En fait, le problème se situe au niveau de la rédaction du cahier des charges / écriture des spécifications : le client ne demande pas cette option, donc on ne la fait pas.

Potentiellement, mauvais boulot de la part du mec chargé de l'écriture des spécifications avec le client.
C'est un problème de la part du Maître d'Ouvrage : il n'avait qu'à exprimer clairement son besoin.
Si il y a chez vous un Maître d'Ouvrage délégué, le problème peut venir de lui : c'est son boulot de "deviner" quels besoins sont implicites et de les proposer au client.

c'est exactement ce que je pensais, merci de l'avoir exprimé de façon claire ^^

ah oui pas mal le if else pour la gestion d'erreurs j'y penserai

Combien de fois j'ai vu dans des tutos php des foreach sur ses tableaux où rien ne garanti la présence de données (base vide où erreur dans la requête) et que l'auteur ne trouve pas choquant d'avoir des warnings à l'écran...

Hum.

Peut être que l'auteur du PEBKAC n'as pas indiqué si oui ou non la liste des données problématiques avaient été fournie.

Du coup ça pourrait carrément changer la donne!

Le try catch ou le switch c'est pour les tapettes!

euh, je lis :
Hum.
Auteur du post

Sortez le sarcasm-o-tron!

Pour moi l'auteur du PEBKAC (notre cher "Hum.", au pseudo évocateur) est d'accord sur le fait qu'un message d'erreur explicite devrait apparaître et que le PEBKAC est justement que l'équipe de dev ne l'ait pas déjà fait.
Les messages d'erreur sont vitaux pour une application.

Sauf dans le cas mythique de l'application sans bug..