> Tech > Protection des instructions SPL

Protection des instructions SPL

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

Les techniques de traitement d'erreurs décrites dans le corps de l'article permettent de protéger toute instruction SQL en l'encadrant par une paire d'instructions comme celles illustrées en H et J sur la figure 1. Cette technique d'encadrement convient pour

Protection des instructions SPL

des instructions Select et autres instructions de manipulation de données
individuelles, mais est trop encombrante pour qu’on l’associe à 
chaque Set, Case, et autre instruction de programmation SPL (Stored
Procedure Language). Bien que les exceptions dans ces instructions de
programmation soient moins probables que dans des instructions de
manipulation de données, elles peuvent néanmoins se produire. Avec le
gestionnaire des exceptions présent en D, figure 1, les exceptions présentes
dans des instructions encadrées sont ignorées et le flux d’exécution
se poursuit.

            Pour
protéger toutes les instructions dans une procédure SQL, on peut étendre
la technique de traitement d’erreurs comme dans la figure A, qui montre
les segments modifiés de la procédure catalogué GetRank de la figure 1.
Cette technique étendue implique de régler la variable ExceptionState
sur ExceptionStateNotChecking avant tout groupe d’une ou plusieurs
instructions dans lequel SQLState n’est pas testé individuellement (B
et D, figure A). Après chaque section de code de ce type, on ajoute une
instruction Leave Main conditionnelle pour quitter la procédure si une
exception se produit pour une instruction quelconque du groupe (en C et E)
(observez comment il s’en suit que la dernière de ces instructions
conditionnelles est l’avant-dernière de la procédure, juste avant de
positionner l’état d’achèvement “ OK ”, comme illustré
en E.) Le seul autre changement nécessaire se trouve dans le gestionnaire
d’exceptions, où il faut donner au paramètre SQLStateOut la valeur
SQLState pour une exception se produisant dans une section du code non
testé (en A) (cela suppose de toujours quitter la procédure quand une
exception survient dans une section non testée du code.)

            Notons
que cette technique ne quitte la procédure qu’à  la fin d’une section
de code non testée, et que la valeur SQLState renvoyée concerne la dernière
exception (il se peut que de multiples instructions dans la section
causent une exception). Sans être parfaite, cette solution permet de
surveiller les exceptions sans trop compliquer le code. On peut utiliser
cette méthode exhaustive selon sa propre “ recette ”, en
combinant les deux morceaux supplémentaires du code avec les deux
morceaux de code correspondants qui encadrent les instructions testées,
comme je l’ai fait dans la figure A juste avant et après
l’instruction Select. Pour simplifier l’utilisation de cette
technique, je garde ces deux tranches de code dans un fichier source et
les place, par copier-coller, de part et d’autre de chaque instruction
testée. –
PC

Téléchargez cette ressource

Guide de technologie 5G pour l’entreprise

Guide de technologie 5G pour l’entreprise

Le livre blanc "The Big Book of Enterprise 5G" vous fournit les informations stratégiques dont vous avez besoin pour prendre des décisions éclairées et préparer votre entreprise à prospérer dans l'ère de la 5G. Cradlepoint, part of Ericsson est le leader mondial des solutions de réseau sans fil 4G LTE et 5G fournies via le cloud. Connectez vos employés, lieux et objets avec la 4G LTE et la 5G pour un WAN sans fil d'entreprise.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010

A lire aussi sur le site

Revue Smart DSI

La Revue du Décideur IT