Discussion :

[loustalet]

Bonjour,

Je développe un projet qui contient pas mal de procédures stockées que je gère dans un package.
Voici un extrait du code d'une procédure d'un package. Cette procédure est surchargée dans le package :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
procedure NOUVEAU(
  ......
  )
  is
 
  errtrop Exception;
  errpasassez Exception;
  errmontant Exception;
   pragma exception_init(errtrop, -20106);
   pragma exception_init(errpasassez, -20107);
   pragma exception_init(errmontant, -20200);
 
 
  begin
  NOUVEAUVEHICULE(...);
 
  INSEREROPTIONS(...);
 
  exception
    when errtrop then
      raise;
    when errpasassez then
      raise;
    when errmontant then
      raise;
    when others then
      raise_application_error(-20103, 'erreur à la création du vehicule '); 
  end NOUVEAU;

ça marche MAIS .... c'est très lourd car les procédures appelées remontent des erreurs parfois déclenchées par des triggers.
J'aimerais limiter ces paragma exception_init et ces when.... raise;
Je dois récupérer les erreurs dans mon application écrite en C# et tester le sqlcode renvoyé. (ça je sais faire)

Je n'arrive pas à trouver de solution qui simplifie mon problème !
J'avais pensé faire un when others then raise; mais ça ne semble pas être une bonne idée !
Que me conseillez-vous ?
Merci

[mnitu]

D’une manière générale supprimez toute la gestion des exceptions dans les procédures. Interceptez et gérez que les exceptions que vous pouvez traiter: c’est à dire vous pouvez trouver une continuation sans remonter l’exception à l’environnement appelant. Toutes les autres exceptions doivent remonter à l’environnement ’appelant; c’est lui qui serait quoi faire des exceptions.

En PL/SQL les exceptions entre dans une des 3 catégories suivantes:

1. Inévitables – comme l’exception NO_DATA_FOUND soulevée par la fin de la lecture d’un fichier via UTL_FILE. Vous est obligé de la gérer.
2. Regrettables – comme l’exception NO_DATA_FOUND soulevée par un select … Into…. Parfois ce type d’exception peut être gérer dans le PL/SQL soit pour ajouter plus des précisions pour les utilisateurs soit par une création de l’entité manquante. Dans les autres cases ce type d’exception doit remonter à l’environnement appelant.
3. Inattendues - comme l’exception TOO_MANY_ROWS soulevée par un Select… Into… Ce type d’exception doit remonter à l’environnement appelant.

En conclusion interceptez que les exceptions que savez gérer.

[skuatamad]

En l'état le gestionnaire d'erreur masque des informations (notemment le when others), il est donc plus difficile de détecter les problèmes :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
SQL> create table t (c varchar2(1) not null);
 
Table created.
 
SQL> create or replace procedure p (p_c t.c%type)as
  2  begin
  3    insert into t (c) values (p_c);
  4  exception
  5    when others then
  6        raise_application_error(-20103, 'erreur dans la proc');
  7  end;
  8  /
 
Procedure created.
 
SQL> exec p('aa');
BEGIN p('aa'); END;
 
*
ERROR at line 1:
ORA-20103: erreur dans la proc
ORA-06512: at "SKUATAMAD.P", line 6
ORA-06512: at line 1
 
 
SQL> exec p(NULL);
BEGIN p(NULL); END;
 
*
ERROR at line 1:
ORA-20103: erreur dans la proc
ORA-06512: at "SKUATAMAD.P", line 6
ORA-06512: at line 1

Alors que sans gestionnaire d'erreur, on a des infos utiles (y compris sur les numéros de lignes) :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
SQL> create or replace procedure p (p_c t.c%type)as
  2  begin
  3    insert into t (c) values (p_c);
  4  end;
  5  /
 
Procedure created.
 
SQL> exec p('aa');
BEGIN p('aa'); END;
 
*
ERROR at line 1:
ORA-12899: value too large for column "SKUATAMAD"."T"."C" (actual: 2, maximum: 1)
ORA-06512: at "SKUATAMAD.P", line 3
ORA-06512: at line 1
 
 
SQL> exec p(NULL);
BEGIN p(NULL); END;
 
*
ERROR at line 1:
ORA-01400: cannot insert NULL into ("SKUATAMAD"."T"."C")
ORA-06512: at "SKUATAMAD.P", line 3
ORA-06512: at line 1
 
 
SQL>

Comme l'a déjà conseillé mnitu :

D'une manière générale supprimez toute la gestion des exceptions dans les procédures. Interceptez et gérez que les exceptions que vous pouvez traiter

[loustalet]

Merci beaucoup pour ces explications qui vont me simplifier la vie!

2 réflexions :

- En fait je ne vais remonter que mes exceptions provenant des triggers qui vérifient des règles de gestion et que je dois traiter dans l'applicatif

- Je ne fais pas apparaitre dans mon application les messages bruts du type :

Code :

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

1
2
3
4
ERROR at line 1:
ORA-12899: value too large FOR COLUMN "SKUATAMAD"."T"."C" (actual: 2, maximum: 1)
ORA-06512: at "SKUATAMAD.P", line 3
ORA-06512: at line 1

Je les remplace par des messages "enregistrement fait" ou "erreur à l'enregistrement" par souci de confidentialité, il n'est pas bon de donner trop d'infos dans aux utilisateurs de l'appli

Merci pour les conseils de bonnes pratiques

[skuatamad]

- Je ne fais pas apparaitre dans mon application les messages bruts du type :
......
Je les remplace par des messages "enregistrement fait" ou "erreur à l'enregistrement" par souci de confidentialité, il n'est pas bon de donner trop d'infos dans aux utilisateurs de l'appli

Oui c'est évident, mais ce n'est pas aux procédures PL/SQL de modifier le code erreur, c'est plus au programme client de gérer le traitement/affichage.
Le programme client peut être une procedure PL/SQL, mais dans ce cas c'est plutôt le C#.

[pachot]

Bonjour,

il n'est pas bon de donner trop d'infos dans aux utilisateurs de l'appli

Oui, mais par contre il est important de les écrire dans un log.
Cordialement,
Franck.

[mnitu]

...
Je les remplace par des messages "enregistrement fait" ou "erreur à l'enregistrement" par souci de confidentialité, il n'est pas bon de donner trop d'infos dans aux utilisateurs de l'appli

Le message "erreur à l'enregistrement" est un cauchemar pour le développeur chargé à maintenir l’application. Il sait que quelque chose à mal tourné mais si'l n’a pas accès aux informations concernant la procédure et l’endroit précis où ça c’est mal passé, il est dans le noir total. Parfois y compris quand ces informations sont disponibles un log du traitement s’impose pour comprendre les causes du problème.

[loustalet]

Bonjour,

Merci pour ces réponses, je vais créer dans c# des entrées dans le journal des évènements windows pour les erreurs que je ne traite pas.
Cordialement