Java est extrêmement souple pour définir et lancer des exceptions définies par l'utilisateur. Plus précisément, on peut utiliser un objet SQLException pour définir une exception avec pratiquement tout SQLCode et SQLState. Mais, après retour d'une procédure stockée Java, DB2 UDB runtime ne traite que certains codes de renvoi. Pour garantir
Erreurs définies par l’utilisateur dans des procédures stockées Java

que la condition d’erreur est bien reconnue par le runtime base
de données et retransmis au processus
appelant, on peut mettre SQLCode à –
438 et SQLState à un état de classe
’38yxx’ dans SQLException. Par souci
de cohérence, je vous conseille
d’adopter une méthode semblable à
celle de la section précédente, Erreurs
définies par l’utilisateur dans des procédures
stockées SQL.
Pour créer la classe de procédure
stockée pour l’implémentation Java de
la procédure stockée externe ModSal, utilisez la commande Qshell suivante :
Java ModSalJ.Java
Vous devez charger le code compilé
dans le répertoire de fonctions
QIBM/UserData/OS400/SQLLib/Functi
on sur l’iSeries. Pour rendre la procédure
stockée Java plus performante,
utilisez la commande CRTJVAPGM
(Create Java Program) :
CRTJVAPGM CLSF( ModSalJ.class) OPTIMIZE(4à˜)
Après avoir créé l’objet programme,
vous devez enregistrer la
procédure stockée avec cette instruction
SQL :
CREATE PROCEDURE
db2user.ModSalJ(
IN i-empno char(6),
IN i-salary dec(9,2))
LANGUAGE JAVA
EXTERNAL NAME ‘ModSalJ!modSalJ’
PARAMETER STYLE JAVA
L’exemple de code de la figure 3
montre la classe Java ModSalJ. On observe
que SQLException est utilisé
pour transmettre les erreurs définies
par l’utilisateur au client.
En A, si le numéro d’employé transmis comme paramètre est incorrect,
un SQLException est lancé pour
signaler qu’une condition d’erreur est
survenue dans la procédure stockée.
En B, le SQLException est lancé
pour signaler que la règle de gestion a
été transgressée. SQLState est mis à
’38S01′ et SQLCode est mis à -438.
Comme une procédure Java est une
procédure stockée externe, vous pouvez
aussi mettre SQLCode à -443, qui
est le code d’erreur utilisé par le runtime
base de données pour indiquer
les conditions d’erreur dans une routine
externe. Dans notre méthodologie,
nous avons tiré parti du fait que
Java est suffisamment souple pour renvoyer
-438 plutôt que -443. Les deux
codes sont traités correctement par le
runtime base de données, mais il vaut
mieux mettre SQLCode à -438 parce
que ce code d’erreur empêche la troncature
du message d’erreur défini par
l’utilisateur.
Le bloc Catch en C intercepte et
lance toutes les conditions d’erreurs
runtime SQL et d’erreurs définies par
l’utilisateur afin qu’elles soient renvoyées
à l’appelant.
Téléchargez cette ressource

État des lieux de la sécurité cloud-native
L’État des lieux de la sécurité cloud-native vous offre une analyse complète des problématiques, des tendances et des priorités qui sous-tendent les pratiques de sécurité cloud-native dans le monde entier. Une lecture indispensable pour renforcer votre stratégie de sécurité dans le cloud. Une mine d’infos exclusives pour élaborer votre stratégie de sécurité cloud-native.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Les PME attendent un meilleur accès aux données d’émissions de la part des fournisseurs
- Fraude & IA : Dr Jekyll vs. Mr Hyde, qui l’emporte ?
- Gestion du cycle de vie des outils de cyberdéfense : un levier de performance pour les entreprises
- Top 6 du Cyber Benchmark Wavestone 2025
- La voix met le clavier au placard : une mutation incontournable pour les entreprises
