Dans Postgres, nous obtenons la "trace de pile" des exceptions en utilisant ce code:
EXCEPTION WHEN others THEN
GET STACKED DIAGNOSTICS v_error_stack = PG_EXCEPTION_CONTEXT;
Cela fonctionne bien pour les exceptions "naturelles", mais si nous levons une exception en utilisant
RAISE EXCEPTION 'This is an error!';
... alors il n'y a pas de trace de pile. Selon une entrée de la liste de diffusion , cela pourrait être intentionnel, bien que je ne puisse pas comprendre pourquoi. Cela me donne envie de trouver une autre façon de lever une exception autre que l'utilisation de RAISE
. Suis-je juste en train de manquer quelque chose d'évident? Quelqu'un at-il une astuce pour cela? Existe-t-il une exception que je peux demander à Postgres de lancer qui contiendrait une chaîne de mon choix, de sorte que j'obtienne non seulement ma chaîne dans le message d'erreur, mais également la trace complète de la pile?
Voici un exemple complet:
CREATE OR REPLACE FUNCTION error_test() RETURNS json AS $$
DECLARE
v_error_stack text;
BEGIN
-- Comment this out to see how a "normal" exception will give you the stack trace
RAISE EXCEPTION 'This exception will not get a stack trace';
-- This will give a divide by zero error, complete with stack trace
SELECT 1/0;
-- In case of any exception, wrap it in error object and send it back as json
EXCEPTION WHEN others THEN
-- If the exception we're catching is one that Postgres threw,
-- like a divide by zero error, then this will get the full
-- stack trace of the place where the exception was thrown.
-- However, since we are catching an exception we raised manually
-- using RAISE EXCEPTION, there is no context/stack trace!
GET STACKED DIAGNOSTICS v_error_stack = PG_EXCEPTION_CONTEXT;
RAISE WARNING 'The stack trace of the error is: "%"', v_error_stack;
return to_json(v_error_stack);
END;
$$ LANGUAGE plpgsql;
Ce comportement semble être voulu par la conception même du produit.
Dans src/pl/plpgsql/src/pl_exec.c
le rappel du contexte d'erreur vérifie explicitement s'il est appelé dans le contexte d'une instruction PL/PgSQL RAISE
et, si tel est le cas, ignore l'émission du contexte d'erreur:
/*
* error context callback to let us supply a call-stack traceback
*/
static void
plpgsql_exec_error_callback(void *arg)
{
PLpgSQL_execstate *estate = (PLpgSQL_execstate *) arg;
/* if we are doing RAISE, don't report its location */
if (estate->err_text == raise_skip_msg)
return;
Je ne trouve aucune référence spécifique à pourquoi c'est le cas.
En interne dans le serveur, la pile de contexte est générée en traitant le error_context_stack
, qui est un rappel chaîné qui ajoute des informations à une liste lors de l'appel.
Lorsque PL/PgSQL entre dans une fonction, il ajoute un élément à la pile de rappel de contexte d'erreur. Quand il quitte une fonction, il supprime un élément de cette pile.
Si les fonctions de rapport d'erreurs du serveur PostgreSQL, comme ereport
ou elog
sont appelées, il appelle le rappel de contexte d'erreur. Mais en PL/PgSQL s'il remarque qu'il est appelé depuis un RAISE
ses rappels ne font rien intentionnellement.
Compte tenu de cela, je ne vois aucun moyen d'atteindre ce que vous voulez sans patcher PostgreSQL. Je suggère de poster du courrier à pgsql-general demandant pourquoi RAISE
ne fournit pas le contexte d'erreur maintenant que PL/PgSQL a GET STACKED DIAGNOSTICS
pour en faire usage.
(BTW, le contexte d'exception n'est pas une trace de pile en tant que telle. Il ressemble un peu à cela car PL/PgSQL ajoute chaque appel de fonction à la pile, mais il est également utilisé pour d'autres détails sur le serveur.)
Vous pouvez contourner cette restriction et faire en sorte que plpgsql émette le contexte d'erreur comme vous le souhaitez en appelant une autre fonction qui déclenche (avertissement, avis, ...) l'erreur pour vous.
J'ai posté une solution pour cela il y a quelques années - dans l'un de mes premiers messages ici sur dba.SE :
-- helper function to raise an exception with CONTEXT
CREATE OR REPLACE FUNCTION f_raise(_lvl text = 'EXCEPTION'
,_msg text = 'Default error msg.')
RETURNS void AS
$func$
BEGIN
CASE upper(_lvl)
WHEN 'EXCEPTION' THEN RAISE EXCEPTION '%', _msg;
WHEN 'WARNING' THEN RAISE WARNING '%', _msg;
WHEN 'NOTICE' THEN RAISE NOTICE '%', _msg;
WHEN 'DEBUG' THEN RAISE DEBUG '%', _msg;
WHEN 'LOG' THEN RAISE LOG '%', _msg;
WHEN 'INFO' THEN RAISE INFO '%', _msg;
ELSE RAISE EXCEPTION 'f_raise(): unexpected raise-level: "%"', _lvl;
END CASE;
END
$func$ LANGUAGE plpgsql STRICT;
Détails:
J'ai développé votre cas de test publié pour démontrer qu'il fonctionne dans Postgres 9.3: