Skip to main content.
July 20th, 2007

Star Wars meets JavaPolis

Il bejug, java user group del Belgio, ha annunciato il tema del javapolis 2007. Dopo 30 anni dal IV episodio, Star Wars incontra il Javapolis.

Chissa cosa stanno architettando per questo evento che sembra diventare sempre più ricco di spunti originali.

javapolis2007

Posted by Simone Federici as Eventi at 9:48 PM CEST

July 13th, 2007

Checked e Unchecked Exceptions

Esistono 2 tipi di eccezioni, Checked e Unchecked.
Le Checked Ex. (ossia controllabili) sono prevedibili, ad esempio invalid input, database error, ecc…

le Unchecked Ex. rappresentano invece degli errori che avvengono a runtime (potremmo definirli dei difetti del programma). Spesso sono causate da errori o dimenticanze di programmazione, o errato modo di usare un proprio oggetto/metodo.

E’ importante programmare usando il minimo possibile le eccezioni, la loro gestione impiega una grande quantità di CPU, memoria e risorse macchina.

Ogni qualvolta è necessario gestirne una, stabilire a chi spetta la sua gestione è importantissimo.

La domanda da porsi è: “chi conosce il come e chi conosce solo il cosa…”

E’ chiaro che delegare la gestione (catch) di una eccezione ad un componente che non conosce l’implementazione implica la creazione di un accoppiamento di troppo.

Un esempio nella vita reale potrebbe essere: chiedo a un professionista di ripararmi la lavatrice, dopo qualche giorno torno e lui mi risponde che il suo bancomat è scaduto.
E’ chiaro che questa risposta non ha senso, ma proviamo a ricostruire cosa è successo: andando a comprare i pezzi necessari per la lavatrice, non è riuscito a pagare perché aveva il bancomat scaduto.

Se tentiamo di modellare questo evento, ci accorgeremmo che l’eccezione “Bancomat scaduto” non doveva arrivare a me, (come lo gestisco?), il professionista avrebbe dovuto filtrare l’eccezione e dirmi, “il pezzo non è ancora disponibile”. (Legge di Demetra)

Se non è Chiaro, la SQLException in una jsp non ci deve arrivare!

Nella modellazione, quindi, è fondamentale impiegare le Checked Ex. in modo molto attento. (valgono tutti i principi OOP)
L’uso delle Unchecked exception (le runtime) o meglio catturare una eccezione di runtime,
in un sistema perfetto non dovrebbe essere mai fatto. dico in un sistema perfetto perche poi per pigrizia spesso e volentieri se ne abusa.

essendo delle eccezioni non dichiarate nelle firme dei metodi, queste eccezioni sono in grado di attraversare tutti i tiers della applicazione fino ad arrivare all’utente. Giusto pensare un sistema per non far vedere l’errore all’utente finale (lo sviluppatore invece le deve vedere).

Quando si crea una firma di un metodo, senza implementarlo, la soluzione migliore è fargli rilanciare una Uncheked Exception tipo “throw new NotYetImplementatedException()”

Insomma, queste eccezioni esulano dalla progettazione di un software, sono molto potenti e anche molto pericolose se lasciate proliferare. Esse dovrebbero sparire nella messa in esercizio.
Citazione dell’anipattern “programming by exception”
Una volta in Sud Africa ho visto un MVC che faceva uso di Una ForwardException
dove il getMessage() restituiva la url della jsp dove forwardare….. esempio lampante di
antipattern :-) NON FATELO…

Posted by Simone Federici as Post at 6:21 PM CEST