Pl/sqlE ...

Design by Contract

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

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 ).

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

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

Pl/sql e Design by Contract

RAFFORZARE MEDIANTE CODICE I VINCOLI DEL CONTRATTO

Asserzioni

Controllo output

Gestione degli errori

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

Asserzione

Asserzionee

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.

Asserzionee

performance

Le procedure di asserzione creano un maggior carico

Il codice da implementare è minimo ma esiste

Il meccanismo delle asserzioni non può essere rimosso

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

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

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

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 Loggate in tabella per successiva analisi messaggio di errore

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_BACKTRACE

Come ho fatto ad arrivare al punto in cui si è verificata l'eccezione ?

DBMS_UTILITY.FORMAT_CALL_STACK