Pl sql contract_desing
- 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