Gestion des erreurs : RAISE EXCEPTION

Imagine, tu écris une fonction qui calcule la moyenne d’un étudiant. Que se passe-t-il si tu essaies de diviser par zéro (genre, si aucune note n’est dispo) ? Si tu balances ce code en prod, l’erreur va vite débarquer sans prévenir. PL/pgSQL te file des outils puissants pour gérer ce genre de trucs, rendant ton code plus solide, safe et agréable à utiliser.

La gestion des erreurs dans PL/pgSQL permet de :

1. Générer des messages qui expliquent ce qui a foiré.
2. Arrêter l’exécution du code en cas d’erreur critique.
3. Logger les soucis pour pouvoir les analyser plus tard.

Niveaux de messages principaux dans PL/pgSQL

PL/pgSQL gère plusieurs niveaux de messages qui aident les devs à diagnostiquer et corriger les problèmes efficacement. Les voici :

• NOTICE : affiche un message d’info. Pratique pour le debug.
• WARNING : avertissement sur un souci potentiel, mais ça n’arrête pas le programme.
• EXCEPTION : erreur critique qui stoppe tout (et rend la main au code appelant).

Niveaux de messages dans PL/pgSQL

Syntaxe de la commande RAISE

Pour générer des messages et gérer les erreurs, on utilise l’instruction RAISE. Voilà la syntaxe de base :

RAISE <niveau du message> 'texte du message' [, variables...];

• <niveau du message> — NOTICE, WARNING, EXCEPTION.
• 'texte du message' — description du souci.
• [variables...] — valeurs en plus à insérer dans le message.

Exemple 1 : utilisation de RAISE NOTICE

Parfois, c’est utile de savoir ce qui se passe dans ta fonction. Genre, pour déboguer une boucle :

DO $$
BEGIN
    FOR i IN 1..5 LOOP
        RAISE NOTICE 'Valeur actuelle de i : %', i;
    END LOOP;
END
$$;

Résultat : Affichage dans la console des lignes Valeur actuelle de i : 1, Valeur actuelle de i : 2 etc. jusqu’à 5.

Exemple 2 : utilisation de RAISE EXCEPTION

Maintenant, imagine que tu écris une fonction qui doit s’arrêter avec une erreur dans certains cas :

DO $$
BEGIN
    IF 1 = 1 THEN
        RAISE EXCEPTION 'Un truc a mal tourné !';
    END IF;
END
$$;

Résultat : l’exécution s’arrête et le message d’erreur s’affiche dans la console.

Utilisation des paramètres dans RAISE

Avec les paramètres, tu peux personnaliser le texte du message. Pour ça, on utilise les placeholders % :

Exemple 3 : insérer des variables dans RAISE

DO $$
DECLARE
    student_name TEXT := 'Ivan';
    average_score NUMERIC := NULL;
BEGIN
    IF average_score IS NULL THEN
        RAISE EXCEPTION 'L’étudiant % n’a pas de moyenne !', student_name;
    END IF;
END
$$;

Résultat : message L’étudiant Ivan n’a pas de moyenne !.

Comme tu vois, % est remplacé par la variable student_name, ce qui rend le message plus clair.

Générer des erreurs personnalisées

Les erreurs, c’est pas juste des imprévus ! Parfois, il faut en créer exprès pour protéger ton code contre de mauvaises données.

Exemple 4 : vérifier les valeurs d’entrée

On va écrire une fonction qui vérifie si un nombre passé en paramètre est négatif, et qui lève une erreur si c’est le cas :

CREATE OR REPLACE FUNCTION check_positive(value NUMERIC)
RETURNS TEXT AS $$
BEGIN
    IF value < 0 THEN
        RAISE EXCEPTION 'Le nombre % est négatif !', value;
    END IF;
    RETURN 'Le nombre est correct.';
END;
$$ LANGUAGE plpgsql;

Testons la fonction :

SELECT check_positive(-5);

Résultat : message d’erreur Le nombre -5 est négatif !.

Si tu passes une valeur positive :

SELECT check_positive(10);

Résultat : Le nombre est correct.

Gestion des erreurs dans le contexte

C’est cool de savoir générer des erreurs. Mais c’est encore mieux de les gérer selon la situation. Pour ça, on utilise le bloc BEGIN ... EXCEPTION.

Structure de gestion des erreurs

BEGIN
    -- Ton code principal
EXCEPTION
    WHEN TYPE_ERREUR THEN
        -- Que faire en cas d’erreur
    WHEN AUTRE_ERREUR THEN
        -- Actions pour une autre erreur
    WHEN OTHERS THEN
        -- Gestion de toutes les autres erreurs
END;

Décryptons les éléments :

• EXCEPTION — mot-clé qui marque le début du bloc de gestion des erreurs.
• WHEN — permet de préciser le type d’erreur à gérer, genre unique_violation ou division_by_zero.
• OTHERS — sert à gérer toutes les erreurs non précisées dans les blocs WHEN.

Exemple 5 : gérer la division par zéro

On va illustrer la gestion d’une erreur avec une fonction de division toute simple :

CREATE OR REPLACE FUNCTION safe_divide(a NUMERIC, b NUMERIC)
RETURNS NUMERIC AS $$
BEGIN
    -- On tente la division
    RETURN a / b;
EXCEPTION
    WHEN division_by_zero THEN
        RAISE WARNING 'Tentative de division par zéro. Je retourne NULL.';
        RETURN NULL;
END;
$$ LANGUAGE plpgsql;

Testons la fonction :

SELECT safe_divide(10, 2);  -- Résultat attendu : 5
SELECT safe_divide(10, 0);  -- Résultat attendu : NULL et avertissement dans la console

Erreurs classiques avec RAISE

Oublier le niveau du message. Si tu oublies de préciser le niveau, PostgreSQL va râler.

Faux :

RAISE 'Message sans niveau';

Correct :

RAISE NOTICE 'Message avec le niveau NOTICE';

Mauvais paramètres. Si tu utilises %, assure-toi de passer le bon nombre de variables.

Faux :

RAISE NOTICE 'Exemple avec paramètre %';

Correct :

RAISE NOTICE 'Exemple avec paramètre %', 'valeur';

Abus. Utiliser RAISE EXCEPTION à tout bout de champ peut interrompre des opérations importantes. Utilise-le avec modération.

Conseils utiles

1. Fais gaffe avec le bloc WHEN OTHERS. Si possible, précise les erreurs à gérer pour éviter de choper des erreurs qui devraient être traitées autrement.
2. Utilise RAISE pour le debug. Ne laisse jamais une erreur sans gestion.
3. Pense à la perf. Gérer les erreurs peut coûter cher, surtout dans les grosses procédures.

Si tu fais tout bien, tes procédures seront solides et pourront encaisser même les plantages les plus inattendus. Ton PM sera super fier de toi !