Negare l'istanziazione!! [Archivio] - Hardware Upgrade Forum

Mezzetti0903

05-02-2003, 20:03

Negare l'istanziazione!! Preferibilmente in C#

Mi potete fare un esempio in qualsisasi linguaggio di come potrebbe essere possibile, se mai è possibile, negare l'instanziazione da costruttore?? ES(un po' cialtrone perchè lo faccio sul momento):

public class Servizi
public Servizi(string username,string password) {
if ((username=="CIAO") && (password=="CIAO")) {
// OK TUTTO A POSTO
}
else { // ANNULLA L'ISTANZA }
}
}
Ora.. potrei che ne so mettere una variabile "isaccessible" = false
che viene controllata da TUTTI i metodi e propietà prima che si eseguino ma..NON MI SEMBRA ELEGANTE
non mi sembra nè

/\/\@®¢Ø

06-02-2003, 09:30

Originally posted by "Mezzetti0903"

Negare l'istanziazione!! Preferibilmente in C#

Mi potete fare un esempio in qualsisasi linguaggio di come potrebbe essere possibile, se mai è possibile, negare l'instanziazione da costruttore?? ES(un po' cialtrone perchè lo faccio sul momento):

public class Servizi
public Servizi(string username,string password) {
if ((username=="CIAO") && (password=="CIAO")) {
// OK TUTTO A POSTO
}
else { // ANNULLA L'ISTANZA }
}
}
Ora.. potrei che ne so mettere una variabile "isaccessible" = false
che viene controllata da TUTTI i metodi e propietà prima che si eseguino ma..NON MI SEMBRA ELEGANTE
non mi sembra nè

Una soluzione potrebbe essere quella di gettare un'eccezione nel costruttore:

public class Servizi
public Servizi(string username,string password) {
if ((username=="CIAO") && (password=="CIAO")) {
// OK TUTTO A POSTO
}
else {
throw Error("blablalba");
}
}

nel codice poi faresti cosi'

...
try {
x = new Servizi("pinco","pallino");
} catch( Error e )
{
...
}

ovviamente al netto degli errori :D . Conosco poco il C# e quindi non so se supporta le eccezioni nel costruttore, devi comunque stare attento che non e' mai una bella cosa cominciare un lavoro (costruire un oggetto) e poi lasciarlo a meta' (lanciando l'eccezione). Prima di lanciare l'eccezione provvedi a "ripulire" quanto fatto, ad esempio liberando risorse se queste non verranno sistemate automaticamente dal garbage-collector.
Una alternativa e' fare una classe apposita che costruisca (o meno) l'oggetto di cui hai bisogno:

public class ServiceFactory
{
public Servizi getService( string username, string password )
{
...
}
}

che ritorna un oggetto se i parametri sono corretti, un null altrimenti. La cosa si puo' anche estendere: in questo caso infatti il vero oggetto ritornato non e' noto, potrebbe essere una sottoclasse di Servizi, e si potrebbe ritornare un oggetto con diritti particolari in base all'utente.

kingv

06-02-2003, 10:00

non conosco C#, ma in Java puoi farlo creando SOLO un costruttore senza argomenti e dichiarandolo private.

cionci

06-02-2003, 10:55

Vuoi che ci sia una sola istanza di quella classe in memoria ?

cn73

06-02-2003, 11:19

In java esiste la classe IllegalArgumentException()...come ti hanno suggerito puoi lanciare un eccezione, ma non generica!

throw new IllegalArgumentException("tuo messaggio");

is very elegant ;)

kingv

06-02-2003, 11:33

Originally posted by "cn73"

In java esiste la classe IllegalArgumentException()...come ti hanno suggerito puoi lanciare un eccezione, ma non generica!

throw new IllegalArgumentException("tuo messaggio");

is very elegant ;)

son punti di vista ma per me lanciare sempre un'eccezione in un costruttore per non fare istanziare un oggetto e' dal punto di vista del design e' orrido, non elegante.

Un'eccezione (come dice il nome) serve a notificare al chiamante che si e' verificato un problema (infrastruturale, NON applicativo) su una chiamata. E' l'intefaccia che fornisci che deve condizionare la chiamata, non un'eccezione!
Se vuoi condizionare l'istanziazione di un oggetto esiste un patter chiamato factory (con decine di varianti) che fa al caso tuo.

tutto IMHO, naturalmente :pig:

cionci

06-02-2003, 11:34

Se io la facessi in C++ farei così...ma funziona grazie ai puntatori...

class Servizi {
Servizi() { /*costruttore di default*/ }; //privato, non richiamabile direttamente
public:
static Servizi* Autentifica(string user, string pass); //deve essere static
};

Servizi* Servizi::Autentifica(string user, string pass)
{
if(user == "ciao" && pass == "ciao")
return new Servizi;
else
return NULL;
}

//Si usa in questo modo:

Servizi *s = Servizi::Autentifica("pippo", "pluto");
if(s)
//allocato
else
//non allocato

Questo metodo è derivato abbastanza direttamente dal design-pattern "Singleton"....

http://www.devhood.com/tutorials/tutorial_details.aspx?tutorial_id=486

cionci

06-02-2003, 12:05

Aggiungo che anche secondo me usare un'eccezione è come ammazzare una mosca con una cannonata...senza contare che è stilisticamente brutto...ma brutto brutto brutto...

Mezzetti0903

06-02-2003, 12:56

Innanzi tutto Grazie a tutti....
L'idea di lanciare l'eccezione è funzionale ma certo.. come dice Cionci... brutta brutta brutta....
Ecco invece è una buona idea l'ultima di /\/\@®¢Ø.... penso che farò così!!

Originally posted by "/\/\@®¢Ø"

Una alternativa e' fare una classe apposita che costruisca (o meno) l'oggetto di cui hai bisogno:

public class ServiceFactory
{
public Servizi getService( string username, string password )
{
...
}
}

che ritorna un oggetto se i parametri sono corretti, un null altrimenti. La cosa si puo' anche estendere: in questo caso infatti il vero oggetto ritornato non e' noto, potrebbe essere una sottoclasse di Servizi, e si potrebbe ritornare un oggetto con diritti particolari in base all'utente.

Grazie a tutti ancora

Tassadar

06-02-2003, 13:08

puoi anche, come diceva kingv, usare un metodo statico per avere l'istanza della classe che ti interessa e dichiarare il costruttore privato:

public class Servizi{
private Servizi(){
super(); //costruttore ereditato da Object
}

public static Servizi getServizi(string username,string password) {
if ((username=="CIAO") && (password=="CIAO")) {
return new Servizi();
}
else {
return null; //oppure throw new IllegalArgumentException("blah blah blah");
}
}
}

cionci

06-02-2003, 13:21

Originally posted by "Tassadar"

puoi anche, come diceva kingv, usare un metodo statico per avere l'istanza della classe che ti interessa e dichiarare il costruttore privato:

public class Servizi{
private Servizi(){
super(); //costruttore ereditato da Object
}

public static Servizi getServizi(string username,string password) {
if ((username=="CIAO") && (password=="CIAO")) {
return new Servizi();
}
else {
return null; //oppure throw new IllegalArgumentException("blah blah blah");
}
}
}

Che è la stessa cosa di quelo che io ho fatto in C++...

Tassadar

06-02-2003, 13:29

esatto :)
Ciao defender :D

Mezzetti0903

06-02-2003, 13:30

..anche :-))

Forse è anzi più chiaro e razionale con il metodo statico...

Grazie ancora :-D

/\/\@®¢Ø

06-02-2003, 13:31

Originally posted by "kingv"

Un'eccezione (come dice il nome) serve a notificare al chiamante che si e' verificato un problema (infrastruturale, NON applicativo) su una chiamata.

Ma questo non ha a che fare col fatto che sia gettata in un costruttore o in un metodo.
Oltretutto l'eccezione (come dice il nome :D) e' semplicemente qualcosa che accade non troppo spesso, e che quindi e' scomodo dover gestire singolarmente, oppure quando avviene non si hanno informazioni sul come comportarsi. Nel caso in oggetto serve poco perche' presumibilmente il login avviene in un solo punto e quindi ha poco senso sostituire un controllo if con un try{...}catch nello stesso punto. Se pero' l'eccezione rientra in una categoria piu' generica di eccezioni si puo' comunque utilizzarla, raccogliendola molto piu' a monte per fare un repulisti con la ramazza e chiudere il tutto il contesto in cui ci si trova (che non e' necessariamente l'applicazione intera).

E' l'intefaccia che fornisci che deve condizionare la chiamata, non un'eccezione!

Non sono d'accordo. Dipende dallo "schema generale", visto anche che l'eccezione serve appunto per spostarsi dal contesto locale.

Se vuoi condizionare l'istanziazione di un oggetto esiste un patter chiamato factory (con decine di varianti) che fa al caso tuo.

Che e' il secondo esempio che ho fatto :D;)
Comunque non e' necessariamente detto che le factory siano la cosa migliore, perlomeno se il solo scopo e' controllare i parametri. In fondo un wrapper attorno al costruttore non e' poi molto differente da un try-catch , e scrivi pure piu' codice.

kingv

06-02-2003, 14:33

Originally posted by "/\/\@®¢Ø"

Ma questo non ha a che fare col fatto che sia gettata in un costruttore o in un metodo.
Oltretutto l'eccezione (come dice il nome :D) e' semplicemente qualcosa che accade non troppo spesso, e che quindi e' scomodo dover gestire singolarmente, oppure quando avviene non si hanno informazioni sul come comportarsi. Nel caso in oggetto serve poco perche' presumibilmente il login avviene in un solo punto e quindi ha poco senso sostituire un controllo if con un try{...}catch nello stesso punto. Se pero' l'eccezione rientra in una categoria piu' generica di eccezioni si puo' comunque utilizzarla, raccogliendola molto piu' a monte per fare un repulisti con la ramazza e chiudere il tutto il contesto in cui ci si trova (che non e' necessariamente l'applicazione intera).

piu' che un qualcosa che accade raramente l'eccezione dovrebbe essere qualcosa che NON dovrebbe accadere in situazioni standard.
mettiamo che tu abbia un'applicazione che controlla il saldo di conto corrente perche' deve fare un bonifico. Se la comunicazione appc (o qualsiasi altra cosa usi per collegarti ad host) crasha ( :muro: fortuna che non faccio il prof di italiano) allora il lancio di una eccezione ad hoc puo' essere giustificato, in modo che nella catena dele chiamate si possa far pulizia e poi abortire la transazione. ma se ti viene risposto che il saldo di cc e' negativo (e quindi il bonifico non lo puoi fare) lanciare una NoTieneDineroException ( :eek: ) e' una ca**ata dal punto di vista del design, perche' questa e' una condizione applicativa che sara' anche rara ma deve essere gestita dal flusso del'applicazione, non deve stravolgerlo.

Originally posted by "/\/\@®¢Ø"

Non sono d'accordo. Dipende dallo "schema generale", visto anche che l'eccezione serve appunto per spostarsi dal contesto locale.

come sopra, perche' lanciare un'eccezione quando puoi scrivere "return false"?

Originally posted by "/\/\@®¢Ø"

Che e' il secondo esempio che ho fatto :D;)
Comunque non e' necessariamente detto che le factory siano la cosa migliore, perlomeno se il solo scopo e' controllare i parametri. In fondo un wrapper attorno al costruttore non e' poi molto differente da un try-catch , e scrivi pure piu' codice.

a me il problema non sembrava controllare i parametri (anche nel costruttore puoi farlo, non occorre una factory) ma impedire (o limitare) l'istanziazione di un oggetto :o

cn73

06-02-2003, 15:14

Lanciare un'eccezione non è affatto brutto, brutto, brutto, brutto... ne tantomeno poco "stilistico". Esiste fior di letterautura su come creare classi di eccezione ad arte per adattarsi agli scopi funzionali.

Allora tanto vale per risolvere il problema del nostro amico controllare a priori, prima di istanziare l'oggetto, che i parametri siano accettabili.

Naturalmente IMHO :cool:

/\/\@®¢Ø

06-02-2003, 15:32

Originally posted by "kingv"

piu' che un qualcosa che accade raramente l'eccezione dovrebbe essere qualcosa che NON dovrebbe accadere in situazioni standard.

Mi sa che intendiamo la stessa cosa :D ;).
Come dicevo sompra l'eccezione e' comoda e giustificata se posso lanciarla in molte parti e raccoglierla in una ( o poche ) cosi' che il codice "in mezzo" puo' fregarsene, a vantaggio della leggibilita'. Un esempio e' quello che fai tu, ma non e' comunque un concetto piu' generale

come sopra, perche' lanciare un'eccezione quando puoi scrivere "return false"?

Il problema non e' il codice che si deve scrivere per segnalare un errore, ma quello per trattarlo ! Se poi devo scrivere cinquanta volte
if ( x != null ){ ... } else { ... } l'eccezione puo' essere una buona soluzione, perlomeno se mi e' permesso gestirla "non in loco" ( ovvero sostituire i suddetti if con altrettanti blocchi "try" non e' la soluzione che propongo io :D)

a me il problema non sembrava controllare i parametri (anche nel costruttore puoi farlo, non occorre una factory) ma impedire (o limitare) l'istanziazione di un oggetto :o
Mi sono espresso male :p comunque la sostanza del mio discorso resta invariata :)

kingv

06-02-2003, 16:03

Originally posted by "/\/\@®¢Ø"

8< 8< 8< 8<

Mi sono espresso male :p comunque la sostanza del mio discorso resta invariata :)

ho riletto il primo post di Mezzetti, sono io che non ho capito 'na ma**a, non avevo letto il codice :o :o :o

comunque la sostanza del mio discorso resta invariata :mc: :pig:

cionci

06-02-2003, 16:39

Originally posted by "cn73"

Lanciare un'eccezione non è affatto brutto, brutto, brutto, brutto... ne tantomeno poco "stilistico". Esiste fior di letterautura su come creare classi di eccezione ad arte per adattarsi agli scopi funzionali.

Non è il fatto di crearsi classi di eccezione che non deve essere fatto, ma usare l'eccezione per riportare un evento che può essere tranquillamente gestito a livello di codice normale...
Sono d'accordo con kingv...l'eccezione deve essere qualcosa che deve rispecchiare un'anomalia nell'esecuzione del flusso abituale del programma... Un'autentificazione non riuscita non mi sembra affatto un fatto anomalo...
Originally posted by "cn73"

Allora tanto vale per risolvere il problema del nostro amico controllare a priori, prima di istanziare l'oggetto, che i parametri siano accettabili.
Infatti è ciò che viene fatto con il metodo static... Il controllo viene effettuato prima di istanziare l'oggetto...
Perchè non faro al di fuori dell'oggetto ? Beh...dipende dal contesto... Se l'autentificazione è logicamente parte integrante dell'oggetto (ad esempio mettiamo che sia una classe di interfacciamento con un DB e che l'autentificazione sia in questo caso la connessione al DB) allora mi sembra logico che il metodo da adottare sia quello postato (soprattutto per poter riusare al meglio la classe)...

dm69

06-02-2003, 23:38

Secondo me le eccezioni dovrebbero essere usate sempre per gestire qualunque situazione non nominale.
Nel caso in questione si chiedeva di negare la creazione di un oggetto qualora non fossero verificate certe condizioni. Se il costruttore lanciasse una eccezione, il ramo di codice che doveva usare l'eventuale oggetto viene terminato senza dover fare alcun check del tipo:
if (p!=NULL)
....
else
...

In programmi di grande dimensione si risparmia una gran quantita' di codice di error handling. Inoltre, spesso, ci si dimentica di fare questo tipo di check e a run time possiamo avere dei crash inattesi.
In questo caso (se si usasse il C++), inoltre, usando l'eccezione possiamo anche evitare l'allocazione dinamica dell'oggetto (che spesso ci si dimentica di deallocare). Infatti non essendo abbligati a tornare un NULL per dire che la creazione e' fallita, possiamo usare l'oggetto come un tipo qualunque:

....
Servizi servizio(user, passwd);
.... // qui' ci arriviamo sole se il check e' superato.

Ciao a tutti.

cionci

07-02-2003, 08:13

Originally posted by "dm69"

Secondo me le eccezioni dovrebbero essere usate sempre per gestire qualunque situazione non nominale.
Appunto...tutto sta nel definire se un'autentificazione fallita è una situazione nominale o no...
Ad esempio se fosse un server POP3...sarebbe una situazione all'ordine del giorno...e quindi nominale...

dm69

07-02-2003, 10:03

Appunto...tutto sta nel definire se un'autentificazione fallita è una situazione nominale o no...
Ad esempio se fosse un server POP3...sarebbe una situazione all'ordine del giorno...e quindi nominale...

No, anche questo caso dovrebbe essere gestito con eccezioni. La differenza e' come l'eccezione viene gestita. Nel caso del server POP3, volendo si potrebbe ripetere il tentativo di connessione. Basta catturare l'eccezione e ripetere l'operazione.

Nel messaggio precedente intendevo dire che con le eccezioni bisognerebbe trattare tutti quei casi in cui in un programma C tradizionale avremmo tornato un numeretto (es. -1) per significare che qualcosa e' andato storto.

kingv

07-02-2003, 10:56

Originally posted by "dm69"

No, anche questo caso dovrebbe essere gestito con eccezioni. La differenza e' come l'eccezione viene gestita. Nel caso del server POP3, volendo si potrebbe ripetere il tentativo di connessione. Basta catturare l'eccezione e ripetere l'operazione.

Nel messaggio precedente intendevo dire che con le eccezioni bisognerebbe trattare tutti quei casi in cui in un programma C tradizionale avremmo tornato un numeretto (es. -1) per significare che qualcosa e' andato storto.

punti di vista.
facendo cosi' ti obblighi a fare in catch di tre eccezioni diverse nel caso la pwd sia sbagliata, l'utente non esista o il db o ldap su cui fai login siano giu', con un appesantimento del codice inutile (a mio parere)

per me l'eccezione rappresenta un vantaggio solo nelle situazioni "che non si dovrebbero verificare", dove il recovery deve essere fatto probabilmente diversi livelli di chiamata piu' "in alto" del punto dove viene generato. In questo caso si apprezza anche la pulizia di design (perche0 ti eviti di dover gestire a mano il -1 di cui fai l'esempio per tutti i metodi della catena di chiamate).

cionci

07-02-2003, 11:04

Non sono affatto d'accordo... Secondo me le eccezioni...anche secondo il nome, devono trattare solo casi eccezionali...
Le eccezioni IMHO devono essere generate solo in situazioni limite...

Avete mai visto un framework OO generare un'eccezione nel caso di un normale errore ? Io no...

dm69

07-02-2003, 11:20

facendo cosi' ti obblighi a fare in catch di tre eccezioni diverse nel caso la pwd sia sbagliata, l'utente non esista o il db o ldap su cui fai login siano giu', con un appesantimento del codice inutile (a mio parere)

Le eccezioni dovrebbero essere tutte derivate da una eccezione es. GenericException, quindi nel codice che deve catturare le eccezioni e' sufficiente mettere:

...
}
catch(GenericException &e)
{
....
}

e catturi tutte le possibili eccezioni che hai definito.
Altrimenti per catturare tutte le eccezioni possibili puoi fare cosi:
}
catch(...)
{
....
}

Se invece vuoi discriminare il tipo di errore che si e' verificato in modo da intraprendere differenti azioni, allora bisogna fare il catch di tutte le eccezioni che interessano. In questa evenienza l'approccio tradizionale sarebbe stato quasi identico: invece di fare catch di diverse eccezioni bisognava fare uno switch con tanti case quanti sono i codici di errore di interesse.

cionci

07-02-2003, 11:32

Se catchi (!!!) solo l'eccezione base allora è inutile farlo perchè appunto non puoi discriminare fra le varie eccezioni e quale istruzione l'ha generata (a meno di mettere un blocco try piccolissimo)...

Nel caso di includere tutti i vari blocchi catch con le eccezioni specializzate...in questo modo si individua il tipo di errore, ma comunque non si invidua l'istruzione che l'ha generata (a meno di trucchi o di un blocco try con una sola istruzione)...senza contare che bisogna conoscere la gerarchia delle varie eccezioni (cosa alquanto scomoda, già per uno sviluppatore, ma soprattutto per l'utente finale)...

/\/\@®¢Ø

07-02-2003, 11:42

Originally posted by "kingv"

per me l'eccezione rappresenta un vantaggio solo nelle situazioni "che non si dovrebbero verificare", dove il recovery deve essere fatto probabilmente diversi livelli di chiamata piu' "in alto" del punto dove viene generato. In questo caso si apprezza anche la pulizia di design (perche0 ti eviti di dover gestire a mano il -1 di cui fai l'esempio per tutti i metodi della catena di chiamate).
Io sono molto piu' pragmatico : posso evitare piu' controlli con un unico blocco try-catch ? Uso le eccezioni. Non lo posso fare ? Non le uso. Semplice :D. Proprio per questo la libreria standard del C++ permette di usare entrambi gli approcci ;)

kingv

07-02-2003, 11:44

Originally posted by "dm69"

catch(...)
{
....
}

mi sa che stai facendo un po' di casino tra C++ e java :p :p

per il resto la penso esattamente come nell'ultimo post di cionci.

kingv

07-02-2003, 11:47

Originally posted by "/\/\@®¢Ø"

Io sono molto piu' pragmatico : posso evitare piu' controlli con un unico blocco try-catch ? Uso le eccezioni. Non lo posso fare ? Non le uso. Semplice :D. Proprio per questo la libreria standard del C++ permette di usare entrambi gli approcci ;)

il c++ ti permette di usare qualsiasi cosa perche' e' un po' putt*** :sofico:

/\/\@®¢Ø

07-02-2003, 11:57

Originally posted by "kingv"

il c++ ti permette di usare qualsiasi cosa perche' e' un po' putt*** :sofico:
Molto meglio di Java che ti infila giu' per la gola le eccezioni anche quando non ti servono... col risultato che alcuni le bypassano mettendo un "catch(Exception e)" nel main e basta :eek: :p
O dove per farmi un vettore di int devo trasformarli in Integer e poi farmi un cast da Object a Integer quando li estraggo e infine riprendermi l'int... :D :p

dm69

07-02-2003, 12:28

dm69 ha scritto:

catch(...)
{
....
}

mi sa che stai facendo un po' di casino tra C++ e java

per il resto la penso esattamente come nell'ultimo post di cionci.

Mi sa' che devi vedere qualche libro sul C++.
Forse non hai mai visto l'espressione:

catch(...)

I 3 punti nel catch del C++ significa che cattura TUTTE le eccezioni.
Assomiglia vagamente al finally di Java.

dm69

07-02-2003, 12:45

Nel caso di includere tutti i vari blocchi catch con le eccezioni specializzate...in questo modo si individua il tipo di errore, ma comunque non si invidua l'istruzione che l'ha generata (a meno di trucchi o di un blocco try con una sola istruzione)...

Al codice chiamante non interessa sapere l'esatto statement che ha dato errore, al chiamante interessa sapere che qualcosa e' andato male, quindi basta che il codice chiamato generi un eccezione di tipo diverso per ogni errore che deve riportare (es. nel nostro caso: PasswordCheckException, BadUserNameException, ...) possibilmente tutte figlie della stessa classe di eccezione.
Per quanto riguarda il chiamante, non deve assolutamente catturare alcunche' (senno' torniamo di nuovo all'approccio C) a meno che non debba intraprendere azioni di recovery. Infatti se il chiamante non cattura l'eccezione, semplicemente viene terminato e si sale al suo chiamante e cosi' via. Questo risparmia il test if (res == -1) ... come ho gia detto.

senza contare che bisogna conoscere la gerarchia delle varie eccezioni (cosa alquanto scomoda, già per uno sviluppatore, ma soprattutto per l'utente finale)...

La gerarchia delle eccezioni la devi conoscere solo se devi fare azioni diverse a seconda dell'errore occorso. Lo stesso problema c'e' con la libreria del C: ogni funzione ritorna un numeretto che dice se tutto e' andato bene o no. Se poi vuoi proprio sapere che cosa e' successo ti devi studiare la documentazione e fare uno switch su errno.

cionci

07-02-2003, 13:09

Originally posted by "dm69"

Al codice chiamante non interessa sapere l'esatto statement che ha dato errore, al chiamante interessa sapere che qualcosa e' andato male, quindi basta che il codice chiamato generi un eccezione di tipo diverso per ogni errore che deve riportare (es. nel nostro caso: PasswordCheckException, BadUserNameException, ...) possibilmente tutte figlie della stessa classe di eccezione.
Infatti per "identificare l'istruzione" non intedevo l'istruzione all'interno della funzione che ha provocato il lancio dell'eccezione...ma quale istruzione all'interno di un blocco try ha generato l'eccezione... Mettiamo caso che ci siano 2 funzioni all'interno del blocco try che possono lanciare gli stessi tipi di eccezione...come faccio a sapere con la catch quale delle due ha generato l'eccezione ?
Originally posted by "dm69"

La gerarchia delle eccezioni la devi conoscere solo se devi fare azioni diverse a seconda dell'errore occorso. Lo stesso problema c'e' con la libreria del C: ogni funzione ritorna un numeretto che dice se tutto e' andato bene o no. Se poi vuoi proprio sapere che cosa e' successo ti devi studiare la documentazione e fare uno switch su errno.
Io non parlavo di identificare il tipo di errore, ma di identificare la funzione all'interno del blocco try che l'ha generato...
Metti che ci siano funzioni diverse all'interno del try e che ognuna possa lanciare un'eccezione diversa... Allora se volessi gestire gli errori di ogni funzione dovresti mettere una catch per ogni tipo di eccezione...
Mettiamo ora che queste eccezioni magari siano derivate l'una dall'altra...
A questo punto devi sapere la gerarchia delle eccezioni prima di poter disporre i blocchi catch nel modo giusto...non ti torna ?

kingv

07-02-2003, 13:26

Originally posted by "dm69"

Mi sa' che devi vedere qualche libro sul C++.
Forse non hai mai visto l'espressione:

catch(...)

I 3 punti nel catch del C++ significa che cattura TUTTE le eccezioni.
Assomiglia vagamente al finally di Java.

davvero? mi consigli qualche titolo?

dato che tutti gli esempi che abbiamo fatto fin ora erano riguardo a java e tu sei venuto fuori con un costrutto tipico del c++ ti ho fatto notare che forse stavi confondendo le cose...

"finally" e' totalmente doverso dal catch(...) del c++, il blocco di codice che contiene viene eseguito in ogni caso, sia che le istruzioni dentro il try generino un'eccezione sia in caso contrario.

il corrispondente java del catch(...) e' un catch(Exception ex), dato che tutte le eccezioni (anche quelle Runtime) sono figlie di java.lang.Exception.

kingv

07-02-2003, 13:32

/\/\@®¢Ø

07-02-2003, 13:34

Originally posted by "cionci"

Infatti per "identificare l'istruzione" non intedevo l'istruzione all'interno della funzione che ha provocato il lancio dell'istruzione...ma quale istruzione all'interno di un blocco try ha generato l'istruzione... Mettiamo caso che ci siano 2 istruzioni che possono lanciare gli stessi tipi di eccezione che stanno all'interno del blocco try...come faccio a sapere con la catch quale delle fue ha generato l'eccezione ?

In generale questo e' proprio cio' che non si vuole fare con le eccezioni: l'idea e' "e' accaduto un errore di un certo tipo, e quindi lo gestisco in un certo modo , a prescindere da dove e' accaduto (anche perche' forse dove e' successo non potrei gestirlo)". E' comunque possibile gestire casi particolari, basta sbizzarrisci con le classi: se ad esempio basta sapere la causa dell'errore per loggarlo si puo' usare un metodo "what()" che ritorni una stringa con un messaggio. Ovviamente se devi distringuere tutti i possibili punti in cui avviene un errore , le eccezioni non ti servono.

Io non parlavo di identificare il tipo di errore, ma di identificare la funzione all'interno del blocco try che l'ha generato...
Metti che ci siano funzioni diverse all'interno del try e che ognuna possa lanciare un'eccezione diversa... Allora se volessi gestire gli errori di ogni funzione dovresti mettere una catch per ogni tipo di eccezione...
Mettiamo ora che queste eccezioni magari siano derivate l'una dall'altra...
A questo punto devi sapere la gerarchia delle eccezioni prima di poter disporre i blocchi catch nel modo giusto...non ti torna ?
Molto spesso e' sufficiente definire un metodo da ridefinire nelle sottoclassi che ritorni cio' che ci serve. Ancora una volta, se per ogni funzione devi definirti una classe derivata, le eccezioni non sono quel che ti serve.

cionci

07-02-2003, 13:39

Originally posted by "/\/\@®¢Ø"

Molto spesso e' sufficiente definire un metodo da ridefinire nelle sottoclassi che ritorni cio' che ci serve. Ancora una volta, se per ogni funzione devi definirti una classe derivata, le eccezioni non sono quel che ti serve.
Oh...ecco quello che intendevo io...ma mi sembra che dm69 abbia detto il contrario : "intendevo dire che con le eccezioni bisognerebbe trattare tutti quei casi in cui in un programma C tradizionale avremmo tornato un numeretto (es. -1) per significare che qualcosa e' andato storto"

dm69

07-02-2003, 13:43

"finally" e' totalmente doverso dal catch(...) del c++, il blocco di codice che contiene viene eseguito in ogni caso, sia che le istruzioni dentro il try generino un'eccezione sia in caso contrario.

Infatti ho detto che assomiglia vagamanete!

il corrispondente java del catch(...) e' un catch(Exception ex), dato che tutte le eccezioni (anche quelle Runtime) sono figlie di java.lang.Exception.

Beh se vogliamo essere precisi non e' Exception, ma Throwable!

kingv

07-02-2003, 13:57

Originally posted by "dm69"

Beh se vogliamo essere precisi non e' Exception, ma Throwable!

se fai un catch(Throwable) beccheresti anche le istanze di java.lang.Error (e sottoclassi). Quindi anche i vari OutOfMemoryError ecc. ecc. che e' impossibile gestire da codice :o

dm69

07-02-2003, 14:05

dm69 ha scritto:

Beh se vogliamo essere precisi non e' Exception, ma Throwable!

se fai un catch(Throwable) beccheresti anche le istanze di java.lang.Error (e sottoclassi). Quindi anche i vari OutOfMemoryError ecc. ecc. che e' impossibile gestire da codice

catch(...) prende qualunque eccezione senza distinzione, quindi e' Throwable.

kingv

07-02-2003, 14:14

Originally posted by "dm69"

catch(...) prende qualunque eccezione senza distinzione, quindi e' Throwable.

non mi hai capito: sintatticamente e' quello (Throwable), ma non e' saggio fare il catch di qualcosa che non si puo' gestire, per cui e' meglio usare catch(Exception).

dm69

07-02-2003, 19:43

dm69 ha scritto:
Al codice chiamante non interessa sapere l'esatto statement che ha dato errore, al chiamante interessa sapere che qualcosa e' andato male, quindi basta che il codice chiamato generi un eccezione di tipo diverso per ogni errore che deve riportare (es. nel nostro caso: PasswordCheckException, BadUserNameException, ...) possibilmente tutte figlie della stessa classe di eccezione.

Infatti per "identificare l'istruzione" non intedevo l'istruzione all'interno della funzione che ha provocato il lancio dell'eccezione...ma quale istruzione all'interno di un blocco try ha generato l'eccezione... Mettiamo caso che ci siano 2 funzioni all'interno del blocco try che possono lanciare gli stessi tipi di eccezione...come faccio a sapere con la catch quale delle due ha generato l'eccezione ?

Se le due funzioni avessere tornato gli stessi numeretti nel caso di approccio C, come avresti fatto a capire chi delle 2 e' andata in errore?
Quello che poni non e' un problema delle eccezioni ma e' un problema di cattiva gestione dell'errore. Infatti se il chiamante deve capire esattamente cosa e' successo dobbiamo fare il throw di eccezini diverse oppure tornare numeretti diversi nel caso C.

dm69 ha scritto:
La gerarchia delle eccezioni la devi conoscere solo se devi fare azioni diverse a seconda dell'errore occorso. Lo stesso problema c'e' con la libreria del C: ogni funzione ritorna un numeretto che dice se tutto e' andato bene o no. Se poi vuoi proprio sapere che cosa e' successo ti devi studiare la documentazione e fare uno switch su errno.

Io non parlavo di identificare il tipo di errore, ma di identificare la funzione all'interno del blocco try che l'ha generato...
Metti che ci siano funzioni diverse all'interno del try e che ognuna possa lanciare un'eccezione diversa... Allora se volessi gestire gli errori di ogni funzione dovresti mettere una catch per ogni tipo di eccezione...
Mettiamo ora che queste eccezioni magari siano derivate l'una dall'altra...
A questo punto devi sapere la gerarchia delle eccezioni prima di poter disporre i blocchi catch nel modo giusto...non ti torna ?

Anche questo non e' un problema delle eccezioni, e' un problema di cattivo design: numeretti o eccezioni e' lo stesso!

dm69

07-02-2003, 20:03

Oggetto: Re: x cionci

--------------------------------------------------------------------------------

dm69 ha scritto:

Al codice chiamante non interessa sapere l'esatto statement che ha dato errore, al chiamante interessa sapere che qualcosa e' andato male, quindi basta che il codice chiamato generi un eccezione di tipo diverso per ogni errore che deve riportare (es. nel nostro caso: PasswordCheckException, BadUserNameException, ...) possibilmente tutte figlie della stessa classe di eccezione.

ti troveresti ad avere in un progetto decine (o centinaia) di eccezioni, con nessun vantaggio e un sacco di manutenzione in piu'.
in un driver jdbc secondo la tua teoria dovrebbero essere contenute qualcosa tipo 3-4mila classi di eccezione diverse (e se volessi sapere esattamente che errore ha generato una connect o uno statement dovresti scrivere un corrispondente numero di catch)

Se progettiamo con i piedi si!
Sistemi che usano le eccezioni per l'error handling tendono a definire parecchie eccezioni (il sistema che sto sviluppando al momento attuale consta di circa 200.000 righe di codice e ci sono una trentina di eccezioni).
Non e' detto che per ogni errore bisogna avere una eccezione diversa: per esempio un errore di lettura / scrittura / apertura / chiusura di un file si puo' reppresentare ad esempio con FileSystemException e dentro si puo mettere una stringa che da' un informazione dettagliata di cosa e' successo.

Secondo me avete una idea sbagliata della gestione delle eccezioni: le eccezioni non si devono catturare quasi mai, ha senso farlo solo se dobbiamo effettuare delle azioni di recovery, altrimenti le possiamo bellamente ignorare. Infatti provedono loro a terminare la funzione da cui e' saltata fuori l'eccezione e tutti i chiamanti finche' non arriviamo a un chiamante che deve prendere la contromisura all'errore che gli e' tornato.

Un codice che usa l'approccio C tende a essere cosi':

....

int ret_code = 0;

ret_code = f1();
if (ret_code == E_ERROR_CODE)
{
return E_ERROR_CODE;
}

ret_code = f2();
if (ret_code == E_ERROR_CODE)
{
return E_ERROR_CODE;
}

ret_code = f3();
if (ret_code == E_ERROR_CODE)
{
return E_ERROR_CODE;
}

....

un codice che usa le eccezioni tende a essere cosi:
.....
f1();
f2();
f3();
....

Non c'e' paragone no?

cionci

08-02-2003, 08:04

Originally posted by "dm69"

Secondo me avete una idea sbagliata della gestione delle eccezioni: le eccezioni non si devono catturare quasi mai, ha senso farlo solo se dobbiamo effettuare delle azioni di recovery
Infatti, ma mi sembra in contrapposizione con quello che dicevi tu ;)
Originally posted by "dm69"

Un codice che usa l'approccio C tende a essere cosi':

Ma un codice del genere come diventerebbe con le eccezioni ?

if (f1() == E_ERROR_CODE)
Disconnetti();

if (f2() == E_ERROR_CODE)
PincoPallino();

if (f3() == E_ERROR_CODE)
TizioCaio();

Ma che stai scrivendo con 200.000 linee ?

dm69

08-02-2003, 09:55

Ma un codice del genere come diventerebbe con le eccezioni ?

if (f1() == E_ERROR_CODE)
Disconnetti();

if (f2() == E_ERROR_CODE)
PincoPallino();

if (f3() == E_ERROR_CODE)
TizioCaio();

In questo caso ovviamente bisognerebbe avere un try/catch per ogni chiamata.

Pero' il caso che proponi a me non capita quasi mai, perche' generalmente se qualcosa va' storto le operazioni di recovery le fanno i distruttori di oggetti creati lungo la sequenza di oparazioni.

Es:

RemoteConnection conn(hostname, port); // il costruttore si connette a un server remoto e lancia eccezione se qualcosa va' storto. Il distruttore si disconnette.

DB_Connection db_conn(db_name, username, passwd); // come sopra ma a un RDBMS

Results query_results; // oggetto che contiene i risultati della query. Il distruttore dealloca la memoria

db_conn.executeSomeQuery(query_results); // query_results viene riempito con i risultati della query. Lancia eccezione se qualcosa va male

conn.sendData(query_results); // per esempio i dati vengono mandati al server remoto. Lancia eccezione se qualcosa va storto.

Questo codice e' exception safe senza nessun try/catch e senza nessun ramo di codice di error handling! Fallo con un approccio classico e ti rendi conto di quanto codice noioso e error prone avresti dovuto scrivere.

Convinto?