Gestion des erreurs dans les nouvelles commandes 4D

Autant, je comprends l’utilité de la commande APPELER SUR ERREUR avec les anciennes commandes 4D qui ne retournaient rien(ou quasi rien), autant, pour les nouvelles commandes qui retournent maintenant un objet complet avec un .sucess (etc.), quelle est l’utilité de continuer à obliger l’utilisation de la commande APPELER SUR ERREUR pour avoir un comportement attendu c’est à dire sans retour d’erreur intempestif qui ne sert plus à rien dans ce cas ? Le but étant qu’une commande soit MAINTENANT silencieuse (FACELESS) et qu’elle retourne ces erreurs éventuellement dans un fichier de log.

La nouvelle commande dont je parle est : SMTP_transporteur.send( )

Merci de vos éclaircissements.

1 Like

C’est sans doute historique et lié au fait que les commandes SMTP n’étaient à l’origine pas intégrées au moteur 4D.

Il y a donc la gestion des erreurs des plugins et la gestion du moteur 4D… rien de surprenant.

Je ne suis pas votre raisonnement ? Il s’agit d’une NOUVELLE commande (elle n’a RIEN d’historique) qui introduit la possibilité de ressortir un objet complet OÙ est l’intérêt de conserver un ancien système de traitement des erreurs archaïque pour CETTE commande ? :thinking:

ben la couche SMTP était bien dispo via le plugin Internet Commands non ?

Oui, mais quel rapport avec la nouvelle implémentation de la gestion des erreurs dans la nouvelle commande ? (Cette nouvelle commande est intégrée à 4D directement et n’a plus aucun rapport avec Internet Commands).

selon la doc 4D il est bien précisé qu’il y a 2 niveaux d’erreurs :

  • le premier lié à une mauvaise configuration des attributs de l’objet (email par exemple) et dans ce cas c’est logique (historiquement) que ce soit 4D qui gère à travers APPELER SUR ERREUR,
  • le deuxième niveau qui est lié à une erreur de traitement d’une des méthodes de l’objet ( transporter par exemple).

4D pourrait effectivement proposer une méthode check pour contrôler la cohérence des attributs des objets en dehors des fonctions liées aux objets…

Dans ce cas, un seul niveau de traitement sans la couche APPELER SUR ERREUR pourrait être proposé au développeur.

Bon, là, c’est moi qui comprend plus rien.

Prenons un exemple concret :
Erreur N°30 : Echec de création d’un socket connecté

C’est quoi ce truc ? Un problème de paramètre ou un paramètre obligatoire manquant ?
Franchement c’est pas clair le mieux serait de transférer cette alerte dans l’objet pour ne PAS polluer le client final qui lui ni comprendra de toute façon rien et à la limite de détailler dans un log d’erreur pour qu’on puisse comprendre ce qu’il se passe.

Actuellement, ce message n’est PAS informatif et ne me sert à rien au contraire.

Bonjour

Pour info, les commandes du transporter SMTP n’utilisent pas la couche SMTP des Internet Commands…

Merci pour cette précision.

Comment expliquer le questionnement de Manuel ?
Comment peut-on l’aider ?

Il y a plusieurs choses ; effectivement un questionnement précis sur un cas précis, mais également une réflexion sur le fond de comment sont gérés actuellement les erreurs ceci afin d’améliorer la chose car actuellement le résultat obtenu est complètement l’inverse de ce que JE souhaiterais avoir… :pensive:

Cette erreur, je l’obtiens en plus sur mon serveur ! pour que vous compreniez mieux mon problème.

Cette alerte bloque le serveur inutilement, elle ne sert à rien vu que les clients finaux ne la voient pas et même s’ils la voyaient cela n’arrangerait pas.

La gestion des erreurs DEVRAIT être, maintenant, de plus en plus, faite via des logs pour ne plus interrompre l’exécution inutilement.

Je vais donc entourer pour l’instant la commande par un APPELER SUR ERREUR mais bon…

Si on souhaite traiter l’erreur, on doit le faire, donc quel intérêt de nous OBLIGER à masquer la vieille gestion d’erreur qui ne nous sert plus. :roll_eyes:

    • J’en profite pour remonter ma demande d’ implémentation sur la pertinence des messages d’erreur
    • J’en profite pour plussoyer mon camarade : devoir implémenter une gestion d’erreur quand il n’y a pas de From, étonnant non ?

En fait c’est tout le code qu’il est conseillé “d’encadrer”, surtout celui qui s’exécute sur serveur.

C’est bien cela que je reproche : Pourquoi faut-il faire cela ? Et pourquoi est-ce à nous de le faire ?

Si on gère correctement les erreurs (avec les retours des objets) l’ancien système n’a plus d’intérêt (il n’en avait déjà pas beaucoup !). Qu’on nous laisse le choix de gérer correctement les erreurs (ou non) mais, actuellement, on n’a PAS le choix ; l’erreur “pop”, et l’utilisateur n’y comprend rien, cela arrête le programme, bref, que de choses qui ne servent strictement à rien… Il faudrait inverser le système. Par défaut TOUTES les erreurs sont loguées, sauf si on demande le contraire. On nous laisse utiliser (ou non) les objets résultats qui contiennent ce qu’il faut pour gérer les erreurs comme on le souhaite.

Bonjour,

Oui, sur le fond, puisque la commande dont vous parlez renvoi un objet status (ce qui n’est pas le cas de toutes les commandes, même nouvelles), il n’y pas de vraie nécessité de jeter une erreur… (à part le pur bonheur de faire râler les développeurs évidemment :wink:)

Je vous suggère d’envoyer un bug report pour exprimer votre point de vue.

Cordialement
Yannick

Comment on fait la différence entre une erreur “normale” et un bug dans ce cas ? :grimacing:
Le but c’est pas de râler pour râler, mais râler pour faire avancer les choses… :wink:

Si la réponse m’est adressée il a été répondu “standard behaviour”

On va bien voir si j’ai plus de chance que toi… :wink:

En tant que développeur, je vais passer mon temps à demander le contraire :wink:

Rien n’interdit d’imaginer un mode spécifique pour le développement. Actuellement, ce qui existe n’est ni bon pour les développeurs ni bon pour les utilisateurs finaux. Pour les développeurs il n’y a JAMAIS assez d’informations (ex : le fait que la partie “détaille” soit masquée est pénible, il faut demander constamment à refaire la capture aux clients qui vous adressent une erreur. Mais le message qui s’affiche est Intéressant s’il est instructif (s’il est tellement vague qu’il ne sert à rien cela n’a aucun intérêt pour le client, ni pour nous (développeur)).

Le fait d’avoir un log serait TRÈS Intéressant pour pouvoir avoir un retour complet, voir faire des stats sur les points à améliorer en priorité.

Une refonte du dialogue d’erreur serait peut-être à envisager également. Pourquoi conserver les boutons tracer et éditer grisés pour les utilisateurs finaux ! ? et au contraire pourquoi cacher/masquer les boutons copier et enregistrer qui est justement ce dont ils ont besoin pour nous donner l’information…

C’est MAL pensé désolé…

C’est pour le moins pas adapté à nos besoins.

Alors on va me dire faites-le vous-même; mais, ce ne serait pas compliqué de nous aider ; même pour nous développeur (en mode développement), d’avoir un complément d’information lorsqu’une erreur “pop” serait un plus (chemin d’appel).

Un truc simple serait d’avoir un mode en interprété et un mode en compilé. (vu que normalement on est censé déployer en compiler pour les utilisateurs finaux…)

Je vous suggère comme je l’ai déjà fait dans ce fil V18 R2 and Zip Create Archive not working? d’ouvrir un sujet (feature request ?) pour discuter de ce dialogue d’erreur. Votre conversation et vos remarques pertinentes sont perdues dans ce sujet. Autant que possible, en évitant de faire ce type de digression, les sujets seront plus clairs pour nos lecteurs et déboucherons plus facilement sur des développements futurs.