[JAVA] Gestire le eccezioni in maniera pulita

[Cosmy]

Ciao a tutti.. sempre nei miei esperimenti per cercare di migrare a java nel minor tempo possibile, mi stavo concentrando sulle eccezioni.
In c++ ero abituato a crearmi un file che conteneva tutte le classi di eccezione che estendevano una classe diciamo elementare, di modo che nel programma basta che intercetti la classe padre senza stare a specificare quale tipo di eccezione è tra quelle che la estendono.

Ora la prima cosa che col java mi torna poco è come fare a mettere più classi in un unico file.
Non posso pensare di creare un file per ogni tipo di eccezione.. le voglio tutte in un unico file insieme all'eccezione di base. Ci sarà un modo per farlo, no?

[andbin]

Originariamente inviato da Cosmy
Ora la prima cosa che col java mi torna poco è come fare a mettere più classi in un unico file.
Non posso pensare di creare un file per ogni tipo di eccezione.. le voglio tutte in un unico file insieme all'eccezione di base. Ci sarà un modo per farlo, no?

In Java tecnicamente è possibile dichiarare più classi (vale anche per interfacce/enum/annotazioni) in un unico file sorgente .java. C'è una sola restrizione: solo 1 classe al massimo può essere dichiarata 'public'. E se tale classe public esiste, allora il nome del sorgente (esclusa l'estensione .java) deve corrispondere esattamente al nome di tale classe.

Comunque per progettini piccoli/semplici può andare bene scrivere più classi/interfacce nello stesso sorgente (i miei Java Examples li ho scritti così ... ma per pura comodità di chi vuole scaricare e leggere i miei esempi).
Per progetti "reali" e di un certo livello è ottima cosa scrivere 1 sorgente per 1 tipo e basta. Se però hai paura di scrivere tanti sorgenti ..... beh, non so che cosa dirti.

[Cosmy]

è più che altro per una questione di pulizia.
Finchè sono 3 sorgenti, va la'... ma ti immagini un progetto più grande che gestisce tanti sorgenti e tanti tipi di eccezioni? Sarebbe un bel macello di file..
L'accademia cosa consiglia di fare per organizzare al meglio lo sviluppo di un progetto ed in particolare le eccezioni?

[andbin]

Originariamente inviato da Cosmy
ma ti immagini un progetto più grande che gestisce tanti sorgenti e tanti tipi di eccezioni? Sarebbe un bel macello di file..

Lo sai che tutti i progetti Java di un certo "livello" sono fatti secondo la regola: 1 tipo "top-level" --> 1 sorgente???
Ed è meglio precisare "top-level" perché ovviamente dentro un tipo si possono dichiarare altri tipi (nested e inner class).

Io per lavoro ho fatto una web application che si può tranquillamente definire "molto piccola" ma ho già scritto 116 file sorgenti .java (senza contare file di configurazione e file di mappatura per Hibernate ecc...)

Ripeto: di che cosa hai paura??

[Cosmy]

ecco questa cosa del top-level mi sfugge completamente.

[LeleFT]

Originariamente inviato da Cosmy
è più che altro per una questione di pulizia.

E' proprio vero che il mondo è bello perchè vario.
Ognuno ha il proprio concetto di "pulizia"...

Se ho un'eccezione che mi viene sollevata da una classe X, non so te, ma io trovo molto più comodo aprire il file X.java (non serve nemmeno cercarlo!) piuttosto che andare in cerca della classe X all'interno di un solo file contenente decine di classi diverse, o peggio, doversi ricordare che la classe X sta dentro al file Y assieme ad altre decine di classi con nomi diversi...

A ciascuna classe il suo file. Ricorda: se viene sollevata un'eccezione, la VM ti dice il nome della classe che l'ha sollevata... e non è forse più comodo/logico andare ad aprire il file con il nome della classe, piuttosto che andare in cerca del posto in cui tale classe è stata salvata?

Per la pulizia sono stati "inventati" i package (chiamati comunemente directory)...

Ciao.

[Cosmy]

capit

[Cosmy]

Vediamo un po' se riesco a perfezionare la tecnica.
Se io nei miei progetti creassi il package/directory per le eccezioni dentro al principale (una cosa tipo: package principale.exceptions)?
complico o semplifico secondo voi?
e poi dopo mi converrebbe lanciarle nel codice richiamando ogni volta exceptions.NomeEccezione oppure facendo import di principale.exceptions?

[andbin]

Originariamente inviato da Cosmy
Vediamo un po' se riesco a perfezionare la tecnica.
Se io nei miei progetti creassi il package/directory per le eccezioni dentro al principale (una cosa tipo: package principale.exceptions)?
complico o semplifico secondo voi?
e poi dopo mi converrebbe lanciarle nel codice richiamando ogni volta exceptions.NomeEccezione oppure facendo import di principale.exceptions?

Generalmente in Java le eccezioni non si mettono in un unico package dedicato alle eccezioni. Ma una eccezione si mette nel package dove il suo uso/significato è più tipico/logico.

Prendiamo il framework di Java SE. Ci sono eccezioni nel package java.awt, java.io, java.lang, java.net, ecc... Non esiste un package es. java.exceptions!!!

IOException dove sta?? È una eccezione legata all'I/O .... sta appunto in java.io. E NullPointerException?? È più "generica" ed è usata innanzitutto dalla JVM ma anche possibilmente da tutto il framework e sta in java.lang.
E SocketException?? È legata alla gestione dei socket. È vero che SocketException estende IOException ma non sta in java.io ... sta in java.net dove ci sono le classi per il networking.

Ok ... hai sicuramente capito. I package comunque, in generale, hanno 3 obiettivi:

1) Servono per definire dei "namespace", che permettono quindi di "qualificare" in modo più completo un tipo e questo ovviamente aiuta ad evitare o perlomeno rende meno probabile un conflitto tra i nomi. java.awt.List e java.util.List sono due tipi che pur avendo come nome "semplice" entrambi List sono tipi ben diversi (la prima è una classe, la seconda è una interfaccia). Ed essendo qualificati con un package possono essere usati entrambi anche in uno stesso progetto.

2) Servono per raggruppare tipi (classi, interfacce, ecc...) che sono in una qualche relazione tra di loro. E tipi in un certo package generalmente vengono anche sempre "impacchettati" insieme in un jar.

3) Servono per sfruttare il livello di accesso di default, detto "package-level". Se non si specifica public/protected/private per classi, metodi, ecc... l'accesso è a livello di "package". Questo permette di dichiarare tipi, metodi, ecc... che sono "visibili" solo all'interno di quel package e quindi non sono "esposti" all'esterno del package.

[Cosmy]

Grazie mille per la trattazione completa. In effetti tenere le eccezioni con le classi che le usano probabilmente ha più senso.

Ma quindi, deviando un po' dall'argomento del topic che ora ho ben digerito, quando ha senso strutturare un package su più livelli?
Se ad esempio sto sviluppando un'applicazione secondo un pattern tipo ModelloVistaControllore, potrebbe avere un senso dividere le classi delle tre diverse funzionalità in diversi sotto-livelli del package?