Discussion :

[Laurent Dardenne]

Bonjour,
j'ai une question triviale qui concerne l'utilisation à outrance, dans la clause exception, de l'exception OTHERS au sein de script PLSQL applicatif.
Par exemple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
BEGIN
 Traitement applicatif
 ...
 EXCEPTION
  WHEN OTHERS THEN
    RAISE_APPLICATION_ERROR(My_Exception,'Echec ...');
END;

J'ai le sentiment que cette approche est discutable mais j'ai un peu de mal à argumenter contre cette maniére de faire étant donné que ça marche ainsi !

A votre avis cela pose un probléme ou pas de ne pas spécifier précisément les cas d'erreurs ?

Quels sont les impacts que peut avoir la déclaration de 5 exceptions applicative au sein d'un package ?

Merci.

PS
Au cas où je précise qu'il s'agit d'une question sérieuse et pas d'un troll.

[star]

A outrance bien sûr que c'est litigieux, car cela veut dire que dans tous les cas d'exception on arrête le processus.
Dans certains cas, une exception doit être traitée en silence et elle ne doit pas se propager aux blocs englobants.
La bonne pratique est de traiter l'exception qui a un sens pour l'application dans le context du bloc dans lequel l'erreur se produit.
.

[Research Am]

Tout code PL/SQL qui sort de mon équipe doit avoir une gestion d'erreur.
Nous insérons le code suivant:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
    EXCEPTION
       WHEN OTHERS THEN
          Gestion_erreur('Erreur dans Fct_lire_ext, code: '||SQLCODE||' - message: '||SQLERRM);

La procédure de gestion d'erreur log dans une table le message et quelques informations supplémentaires selon le programme exécuté et arrête le traitement.

Ça permet à la personne qui s'occupe d'exécuter les traitements d'avoir une façon uniforme de gestion d'erreur.

[SheikYerbouti]

On n'a pas toujours la maîtrise de l'ensemble des exceptions qui peuvent être levées dans un bloc PL/SQL (y compris celles auxquelles on ne pense jamais comme les erreurs système).

Comme il est convenu que toute erreur doit avoir une gestion dans un bloc PL/SQL, WHEN-OTHERS est bien pratique pour trapper les centaines d'erreurs imprévues et ne pas forcément "planter" le programme.

[Laurent Dardenne]

Merci.
Si j'ai bien compris, ce bloc ne doit être utilisé que pour des exceptions imprévues ce qui implique que l'on ne doit pas y gérer des erreurs applicative.

Ce qui me gêne c'est que si chaque procédure posséde un bloc de ce type, la propagation de l'exception, lors d'appels imbriqués, me rammeneras la derniére rencontrée.

Et si j'utilise le paramètre True, pour récupérer 'l'historique' des exceptions déclenchées, la zone mémoire (pile d'appel ?) peut-elle être rapidement saturée ?

[star]

ce bloc ne doit être utilisé que pour des exceptions imprévues ce qui implique que l'on ne doit pas y gérer des erreurs applicative

L'exception others sert effectivement à gérer tous les autres cas d'erreurs non programmées, mais elle n'est pas obligatoire, dans ce cas l'exception se propage.

la propagation de l'exception, lors d'appels imbriqués, me rammeneras la derniére rencontrée

Une exception est propagée si elle n'est pas traité dans le bloc, les blocs englobants et ainsi de suite. Dans ton cas, tu trappes l'exception dans la cause others et relèves une exception applicative avec RAISE_APPLICATION_ERROR. Les exceptions sont différentes. A la place, tu peut relever l'exception avec l'instruction RAISE toute seule.

Et si j'utilise le paramètre True, pour récupérer 'l'historique' des exceptions déclenchées

En rapport avec ma dernière remarque, je ne vois pas l'intérêt d'avoir une cascade d'exceptions applicatives suite à une première qui elle est la bonne.
.

[Laurent Dardenne]

Merci.