Logger en production le moindre appel de method pour une appli qui tourne 24/7 avec potentiellement une forte activite, je suis pas convaincu que ca soit une super idee.
Logger le moindre appel de méthode, c’est même stupide. Mais une ligne de log par mail envoyé et reçu, c’est beaucoup plus raisonnable et ça apporte déjà des informations utiles.
Il est hors de question que je me fade les logs d'une appli, c'est precisement pour eviter ce genre d'emmerdements que j'utilise des produits apple.
Mail est utilise quotidiennement par des dizaines de millions d'utilisateurs, tu crois que ca se saurais pas si yavait de gros problemes qui necessite de se tapper des logs?
Mais qui t’a dit que le problème venait de l’application Mail elle-même ?
Dans l’anecdote que je mentionne, il s’est avéré que le problème ne venait ni de Mail ni même du Mac, mais du serveur SMTP qui était tombé en rade.
Ne rien logger du tout parce qu’on est persuadé que le système et les logiciels sont suffisament bien conçus, c’est complètement idiot parce que c’est oublier que tout ne dépend pas du système ou des logiciels. Mail est certainement bien conçu, mais même lui ne peut pas se connecter à un serveur qui fait le mort.
Une banal ligne dans les logs du genre « cannot reach SMTP serveur: connection timed out », c’est tout ce que je cherchais dans les logs.
Et sans même aller voir les logs, un simple message affiché directement dans l’interface du logiciel, du genre « votre message n’a pas pu être envoyé parce que le serveur d’envoi est injoignable », aurait amplement suffi à mon collègue pour comprendre que le problème venait du serveur et non de sa machine, il n’aurait même pas eu besoin de me déranger. Mais apparemment chez Apple on pense que les messages d’erreur trop explicites font peur à l’utilisateur...
D'un autre cote, se fader les logs d'une appli, c'est pas vraiment ce que j'appelerais une operation de base.
Le simple fait de devoir se les taper c'est signe d'un echec flagrant de l'appli.
Absolument. Dans le cas présent, échec flagrant à signaler à l’utilisateur une condition d’erreur indépendante du logiciel.
[^] # Re: Le dilemme
Posté par gouttegd . En réponse au journal Traumatisme d'Enfance : Le libre et la réalité du terrain. Évalué à 1.
Logger le moindre appel de méthode, c’est même stupide. Mais une ligne de log par mail envoyé et reçu, c’est beaucoup plus raisonnable et ça apporte déjà des informations utiles.
Mais qui t’a dit que le problème venait de l’application Mail elle-même ?
Dans l’anecdote que je mentionne, il s’est avéré que le problème ne venait ni de Mail ni même du Mac, mais du serveur SMTP qui était tombé en rade.
Ne rien logger du tout parce qu’on est persuadé que le système et les logiciels sont suffisament bien conçus, c’est complètement idiot parce que c’est oublier que tout ne dépend pas du système ou des logiciels. Mail est certainement bien conçu, mais même lui ne peut pas se connecter à un serveur qui fait le mort.
Une banal ligne dans les logs du genre « cannot reach SMTP serveur: connection timed out », c’est tout ce que je cherchais dans les logs.
Et sans même aller voir les logs, un simple message affiché directement dans l’interface du logiciel, du genre « votre message n’a pas pu être envoyé parce que le serveur d’envoi est injoignable », aurait amplement suffi à mon collègue pour comprendre que le problème venait du serveur et non de sa machine, il n’aurait même pas eu besoin de me déranger. Mais apparemment chez Apple on pense que les messages d’erreur trop explicites font peur à l’utilisateur...
Absolument. Dans le cas présent, échec flagrant à signaler à l’utilisateur une condition d’erreur indépendante du logiciel.