pl/sql and contract by design

1. Pl/sql
E ...
Design by Contract

2. Design by Contract
In pl/sql Design by Contract = formalizzazione
delle interfacce dei moduli elementari.
 Il soddisfacimento delle precondizioni è
responsabilità del modulo chiamante
 Il soddisfacimento delle postcondizioni è un
obbligo del modulo chiamato
 Gli invarianti sono preservati dal sistema

3. Design by Contract
 Il soddisfacimento delle precondizioni è
responsabilità del modulo chiamante
- I parametri di input debbono soddisfare le
pre-condizioni sia dal punto di vista
formale (data-type) che da un punto di
vista semantico ( il significato del dato in
input è quello che il modulo chiamato si
aspetta ).

4. Design by Contract
 Il soddisfacimento delle postcondizioni è un
obbligo del modulo chiamato
- I parametri di output ed i valori di ritorno
dei moduli debbono obbedire alle post-condizioni
sia da un punto di vista formale
(data-type) che da un punto di vista
semantico (significato del dato) e sono
implementati dagli algoritmi eseguiti dal
modulo

5. Design by Contract
 Gli invarianti sono preservati dal sistema
- La gestione delle eccezioni modifica lo
stato del sistema (da stato normale a
stato di errore) e quindi provoca una
modifica degli invarianti

6. Pl/sql e Design by Contract
RAFFORZARE MEDIANTE CODICE I
VINCOLI DEL CONTRATTO
- Asserzioni
- Controllo output
- Gestione degli errori

7. Asserzione
Le chiamate al modulo hanno obblighi contrattuali
L'asserzione delle precondizioni all'ingresso del modulo
rafforza il contratto
Il rafforzamento delle probabilità che tutti i contratti
siano rispettati aumenta l'affidabilità del codice
L'asserzione:
- Testa una condizione booleana e si lamenta in caso
di violazione
- E' sempre eseguita dal modulo e testa il rispetto
da parte del modulo chiamante delle pre-condizioni

8. Asserzione

9. Asserzione
e
programmazione difesiva
L'asserzione delle precondizioni all'ingresso del
modulo non rende evidente all'esterno l'errore.
E' la routine di gestione degli errori che decide
cosa fare.

10. Asserzione
e
performance
 Le procedure di asserzione creano un maggior
carico
- Il codice da implementare è minimo ma esiste
 Il meccanismo delle asserzioni non può essere
rimosso

11. Spegnere l'Asserzione
 Si può lasciare il codice commentando le
chiamate alle procedure di asserzione
- Le procedure di asserzione sono parte integrante
delle specifiche
 Si può usare la compilazione condizionale
 Eliminare le chiamate solo a fronte di
segnalazioni sulle performance

12. Controllo output
 Dopo l'esecuzione del modulo occorre
controllare l'output prima di restituire il
controllo del processo al modulo chiamante
- Mediante le asserzioni controllo semantico sul dato
restituito

13. Gestione degli errori
Cos'è una eccezione ?
 Accade qualcosa di indesiderabile o inaspettato
Chiamiamo questo eccezione
 Il processo passa dall'esecuzione del blocco normale
all'esecuzione del blocco di eccezioni
 Se il blocco delle eccezioni non riesce a trattare
l'eccezione l'eccezione viene passata al modulo
chiamante

14. Classificazione eccezioni
 Previste,recuperabili, falsi allarmi
 Bisogna preservare il normale flusso del programma usando i
sub-blocks
 Previste ma irrecuperabili
 Ad esempio violazione degli obblighi contrattuali
 Correzione dei moduli per obbedire alle norme dei contratti
 Segnalate al chiamante in modo da permettergli una gestione
 Impreviste ingestibili
 Gestite da when others e loggate in tabella
 Impreviste gestibili

15. Le A.P.I. di Oracle
per segnalare gli errori
Descrizione Come recuperare l'informazione
Codice dell'errore Variabile sqlcode
Messaggio di errore Variabile sqlerrm (massimo 512 byte)
Oppure
DBMS_UTILITY.FORMAT_ERROR_STACK
Individuare la linea di codice dove è stata
sollevata l'eccezione
DBMS_UTILITY.FORMAT_ERROR_BACKTRAC
E
Come ho fatto ad arrivare al punto in cui si è
verificata l'eccezione ?
DBMS_UTILITY.FORMAT_CALL_STACK