Log des erreurs : niveaux de log et format des messages

Là, on est un peu comme des agents secrets — nos fonctions et procédures accomplissent des missions : elles manipulent des données, font des calculs ou juste un peu de magie dans la base. Mais comment savoir si un truc part en vrille ? Comment piger à quel moment le “bain à bulles pour données” a cassé ? C’est là que le logging et la gestion des erreurs entrent en jeu.

Tu te souviens, on a déjà vu comment dans PostgreSQL et PL/pgSQL on peut “communiquer” et écrire dans les logs :

• RAISE NOTICE : ton tranquille, pote — “Hey, tout roule, mais tu veux peut-être jeter un œil à ça”.
• RAISE WARNING : ton un peu plus fort — “Oups, y’a un truc chelou, tu pourrais checker”.
• RAISE EXCEPTION : sirène panique — “STOP ! L’algorithme est en galère ! On a stoppé l’exécution pour éviter la cata”.

Chacun de ces niveaux a son utilité, et c’est important de bien choisir lequel utiliser.

Voilà à quoi ressemblent ces messages dans le code :

DO $$
BEGIN
    -- Niveau NOTICE (tout va bien, juste une info)
    RAISE NOTICE 'Juste une info : début du traitement des données';

    -- Niveau WARNING (un truc suspect)
    RAISE WARNING 'Avertissement : le format des données dans la colonne peut être incorrect';

    -- Niveau EXCEPTION (erreur critique)
    RAISE EXCEPTION 'Erreur : la valeur d’entrée n’est pas valide !';
END $$;

Quand utiliser quoi :

• RAISE NOTICE — pour le debug et l’affichage tranquille d’infos.
• RAISE WARNING — pour prévenir d’éventuelles données foireuses.
• RAISE EXCEPTION — quand il y a une erreur critique qui doit stopper la fonction.

Gestion des erreurs avec RAISE EXCEPTION

RAISE EXCEPTION — c’est ton frein d’urgence. Si un truc part mal, tu peux stopper la fonction et balancer un message d’erreur.

Petit rappel, l’utilisation de base c’est :

RAISE EXCEPTION 'Ton message d’erreur';

Mais pour rendre les messages plus parlants, tu peux utiliser des variables :

DECLARE
    input_value INTEGER;
BEGIN
    input_value := NULL;

    IF input_value IS NULL THEN
        RAISE EXCEPTION 'Erreur : valeur d’entrée NULL. On attendait un INTEGER';
    END IF;
END;

Formatage des messages

Tu peux insérer des variables direct dans le texte du message :

DECLARE
    var1 TEXT := 'Données';
    var2 INTEGER := 42;
BEGIN
    RAISE EXCEPTION 'Erreur lors du traitement de % avec ID %', var1, var2;
END;

Sortie : Erreur lors du traitement de Données avec ID 42.

Exemple : validation des données

Imagine que t’as une procédure qui prend l’âge d’une personne. Si l’âge est négatif, c’est logique de lever une erreur :

CREATE OR REPLACE FUNCTION validate_age(age INTEGER)
RETURNS VOID AS $$
BEGIN
    IF age < 0 THEN
        RAISE EXCEPTION 'L’âge ne peut pas être négatif : %', age;
    END IF;
END;
$$ LANGUAGE plpgsql;

-- Appel de la fonction
SELECT validate_age(-5);  -- Va lever une erreur

Informer avec RAISE NOTICE

Si RAISE EXCEPTION c’est la sirène, RAISE NOTICE c’est la tape amicale sur l’épaule. Ce niveau sert à ajouter des commentaires pour comprendre ce qui se passe dans la fonction.

Quand utiliser RAISE NOTICE :

• Afficher des infos de debug (genre l’état actuel des variables).
• Informer du début d’une étape ou du résultat d’un calcul.

Exemple : messages d’info

CREATE OR REPLACE FUNCTION calculate_discount(price NUMERIC, discount_rate NUMERIC)
RETURNS NUMERIC AS $$
DECLARE
    final_price NUMERIC;
BEGIN
    RAISE NOTICE 'Prix avant remise : %', price;
    RAISE NOTICE 'Taux de remise : %', discount_rate;

    final_price := price - (price * discount_rate);

    RAISE NOTICE 'Prix final : %', final_price;

    RETURN final_price;
END;
$$ LANGUAGE plpgsql;

-- Appel de la fonction
SELECT calculate_discount(100, 0.2);
-- Affiche :
-- NOTICE: Prix avant remise : 100
-- NOTICE: Taux de remise : 0.2
-- NOTICE: Prix final : 80

Cas pratique : planification et logging

Imaginons que t’as une procédure de traitement de données bien costaud, et tu veux savoir à quelle étape elle en est :

CREATE OR REPLACE FUNCTION process_data_step_by_step()
RETURNS VOID AS $$
BEGIN
    RAISE NOTICE 'Étape 1 : Préparation des données';
    -- Ta logique pour la première étape

    RAISE NOTICE 'Étape 2 : Validation des données';
    -- Ta logique pour la deuxième étape

    RAISE NOTICE 'Étape 3 : Sauvegarde des données';
    -- Ta logique pour la troisième étape
END;
$$ LANGUAGE plpgsql;

-- Appel de la fonction
SELECT process_data_step_by_step();
-- Les logs afficheront l’exécution étape par étape

Encore un exemple. Imaginons une boutique qui propose des remises seulement pour les commandes au-dessus d’un certain montant :

CREATE OR REPLACE FUNCTION apply_discount(order_amount NUMERIC)
RETURNS NUMERIC AS $$
BEGIN
    IF order_amount < 50 THEN
        RAISE EXCEPTION 'Erreur : le montant de la commande doit être au moins 50, montant actuel : %', order_amount;
    END IF;

    RETURN order_amount * 0.9;  -- On applique 10% de remise
END;
$$ LANGUAGE plpgsql;

-- Appel de la fonction
SELECT apply_discount(30);  -- Erreur : le montant de la commande doit être au moins 50

Erreurs classiques

Erreur 1 : logger des messages sans paramètres.

Ça donne des logs pas clairs, surtout dans les grosses procédures :

RAISE NOTICE 'Une erreur est survenue';  -- Pourquoi ? Où ? Comment ?

Recommandation : ajoute toujours du contexte :

RAISE NOTICE 'Erreur dans la fonction process_data() : valeur d’entrée : %', input_value;

Erreur 2 : utiliser RAISE EXCEPTION là où un RAISE WARNING suffit.

Si tu balances trop d’exceptions, ton code va s’arrêter pour un rien, et ça va compliquer le traitement des données.

Conseil : choisis bien le niveau de log. Pour le debug, prends NOTICE, pour les cas critiques — EXCEPTION.

Erreur 3 : pas de logging du tout.

C’est comme chercher tes clés dans le noir. Sans logs, débuguer des process compliqués devient quasi impossible.

Conseil : ajoute des RAISE NOTICE aux étapes clés de ta fonction, surtout si elle est grosse et complexe.