[c++] costruttori, distruttori ed eccezioni

[ri]

son cresciuto con questo dogma: "non scrivere mai un costruttore o un distruttore che possano sollevare eccezioni"

non mi sembra una cosa stupida: ad esempio se abbiamo un distruttore che esegue molte operazioni e la prima di queste solleva un'eccezione, che succede alle operazioni successive? non vengono eseguite, ma quindi si avrebbero dei leack di memoria (nell'ipotesi migliore...)

stessa cosa in un costruttore: la new può fallire ed è buona norma verificare il risultato di ogni new immediatamente dopo averla eseguita, ma qual è il comportamento migliore da tenere in questi casi? una throw all'interno del costruttore è contrario alla regoletta sopra, ma non posso sicuramente tenermi un oggetto "con dei problemi" :asd:

quindi mi sorge la domanda: è il dogma sbagliato (o troppo rigido) o mi sfugge qualcosa?

[fek]

quindi mi sorge la domanda: è il dogma sbagliato (o troppo rigido) o mi sfugge qualcosa?

Il dogma cosi' come lo hai enunciato e' parzialmente errato (o parzialmente giusto).

E' sacrosanto non sollevare mai un'eccezione in un distruttore.
I motivi sono vari, uno dei piu' importanti e':

- quando viene sollevata un'eccezione, per Standard C++, gli oggetti locali sullo stack dal punto in cui viene sollevata l'eccezione al punto in cui viene gestita sono distrutti invocando il distruttore (Stack Unwinding); che succede se uno di questi distruttori solleva a sua volta un'eccezione?

Si scatena il panico e sei nella terra dell"Undefined Behavior". Di solito i compilatori C++ chiamano immediatamente terminate() perche' non c'e' modo di uscire da quella situazione. Ma lo Standard non lo impone ed ogni compilatore e' libero di fare quello che gli pare.

Il discorso sul costruttore invece e' diverso; e' buona norma lanciare un'eccezione da un costruttore per riportare una situazione d'errore che ti impedisce di costruire l'oggetto in maniera corretta; ed e' una situazione che accade piuttosto spesso.
Ci sono vari modi per risolverla, ma nessuno e' elegante e semplice da implementare come sollevare un'eccezione, perche' lo Standard C++ in questo caso ti viene in aiuto, imponendo che in caso di eccezione durante la creazioen di un'oggetto dinamico, l'operatore new ritorna NULL.

Esempio:



A* a;

try
{
a = new A();
}
catch (...) // non fatelo mai, indicate sempre l'eccezione di cui fare il trap
{
// a qui e' uguale a NULL perche' e' stata sollevata un'eccezione
// nel costruttore e qualcosa e' andato storto
}

if (a == NULL) // E quanto ci starebbe bene qui un NULL Object Pattern?
{
printf("AAAAAAAAAAAARGH!!!");
}


Senza eccezioni la soluziona sarebbe stata un po' meno elegante:



A* a = new A();

// Devo creare un metodo IsValid() solo per riportare la condizione d'errore

if (!a->IsValid())
{
// E se dimentico di distruggere l'oggetto esplicitamente? LEAK!
delete a;
a = 0;
}

if (a == 0)
{
printf("AAAAAAAAAAAAARGH");
}

[ri]

ottima spiegazione, conferma quanto avevo intuito, ty :D

[RaouL_BennetH]

piccola curiosità su NULL:

Sono alle pagine iniziali del libro di Stroustroup (o come accidenti si scrive :D ) e lui dice che in genere non è una buona idea assegnare a qualcosa il valore NULL ma si dovrebbe preferire il valore zero. E' appunto un suggerimento delle pagine iniziali che poi viene approfondito, o in generale in C++ si fa così ?

Thx.

RaouL.

[ilsensine]

piccola curiosità su NULL:

Sono alle pagine iniziali del libro di Stroustroup (o come accidenti si scrive :D ) e lui dice che in genere non è una buona idea assegnare a qualcosa il valore NULL ma si dovrebbe preferire il valore zero. E' appunto un suggerimento delle pagine iniziali che poi viene approfondito, o in generale in C++ si fa così ?

Dosemu "mappa" memoria perfettamente valida all'indirizzo 0.

Su alcuni sistemi, l'indirizzo "0" è perfettamente valido.

[fek]

piccola curiosità su NULL:

Sono alle pagine iniziali del libro di Stroustroup (o come accidenti si scrive :D ) e lui dice che in genere non è una buona idea assegnare a qualcosa il valore NULL ma si dovrebbe preferire il valore zero. E' appunto un suggerimento delle pagine iniziali che poi viene approfondito, o in generale in C++ si fa così ?

Thx.

RaouL.

Io uso 0. Voi?

[ri]

NULL, trovo che metta in evidenza il fatto che si sta lavorando con un puntatore e non con una variabile normale

e casomai dovessi ricompilare per una piattaforma in cui il NULL non è zero ci vuol poco a ridefinirlo, andare a cambiare gli 0 no :p

[ghiotto86]

Io uso 0. Voi?

io 0 (zero).
è preferibile usare 0 perchè non è detto che NULL sia definito

[maxithron]

in c++ io pure(intendo 0), anche per seguitare a limitare l'uso di macro.

[end.is.forever]

E' buona abitudine eseguire le operazioni che possono scatenare eccezioni in un metodo di inizializzazione invece che nel costruttore, e nel metodo di finalizzazione invece che nel distruttore.

Lo scopo di distruttore e costruttore deve limitarsi all'allocazione e alla liberazione della memoria o poco più.

Stessa cosa per l'acquisizione o il rilascio di risorse, e per le operazioni che possono comportare sospensioni.

[ri]

se il metodo di finalizzazione richiamato dal distruttore solleva eccezioni sei comunque nella merda

[end.is.forever]

se il metodo di finalizzazione richiamato dal distruttore solleva eccezioni sei comunque nella merda

No perchè il metodo di inizializzazione lo chiami dopo il costruttore e il metodo di finalizzazione prima del distruttore.

Ti faccio un esempio, ho una classe che gestisce la connessione con un certo database.
Uno potrebbe pensare di aprire la connessione (con eventuali eccezioni) nel costruttore, e chiuderla nel distruttore.

Molto meglio invece inserire nel costruttore solo l'assegnamento dei campi a seconda dei parametri passati; poi, esplicitamente alla chiamata del metodo di inizializzazione, aprire la connessione. Se si scatena lì l'eccezione è tutto un' altro paio di maniche rispetto al costruttore.
Stessa cosa per distruttore.

[fek]

Molto meglio invece inserire nel costruttore solo l'assegnamento dei campi a seconda dei parametri passati; poi, esplicitamente alla chiamata del metodo di inizializzazione, aprire la connessione. Se si scatena lì l'eccezione è tutto un' altro paio di maniche rispetto al costruttore.
Stessa cosa per distruttore.

Non sono d'accorso sul secondo metodo di inizializzazione, perche' non e' altro che una duplicazione di un concetto che gia' esiste (il costruttore). Perche' matenere due metodi (costruttore e metodo di inizializzazione) quando se ne puo' mantenere solo uno (costruttore)?

Ed inoltre usando un metodo di inizializzazione si perde l'automatismo garantito dallo Standard che distrugge automaticamente l'oggetto in caso di eccezione. Con un metodo di inizializzazione, il programmatore deve ricordare di distruggere l'oggetto ed una riga di codice in piu' siginifica una riga in piu' che magari ci si dimentica di scrivere oppure che puo' introdurre un bug :)

Inoltre, per definizione il costruttore dovrebbe lasciare l'oggetto in uno stato "valido", mentre imporre a cliente dell'oggetto di ricordare di chiamare un'ulteriore metodo per la concludere la costruzione significa imporre un ulteriore complicazione al cliente, complicazione che puo' introdurre un bug (il cliente magari lo dimentica).

Meglio semplificare.

[cionci]

In pratica end.is.forever vuole dire che secondo lui conviene cerare un metodo di finalizzazione da chiamare esplicitamente prima che la classe venga distrutta...

Io aggiungo che è comodo se l'oggetto viene istanziato solo come membro di una classe e non come variabile locale ad un metodo (altrimenti bisogna ricordarsi di finalizzare l'oggetto prima della distruzione automatica), ovviamente IMHO...

[fek]

In pratica end.is.forever vuole dire che secondo lui conviene cerare un metodo di finalizzazione da chiamare esplicitamente prima che la classe venga distrutta...

Io aggiungo che è comodo se l'oggetto viene istanziato solo come membro di una classe e non come variabile locale ad un metodo (altrimenti bisogna ricordarsi di finalizzare l'oggetto prima della distruzione automatica), ovviamente IMHO...

Il metodo di finalizzazione che lancia eventuali eccezioni e' sicuramente una buona idea per ovviare al problema di non poter lanciare eccezioni nel distruttore.

[end.is.forever]

Ovviamente io parlo in teoria, non voglio dire che per ogni classe si debba fare questo.
Io esplicitamente lo faccio poche volte, ma è un pattern che si usa implicitamente spessissimo, quando si vogliono separare le fasi di istanziazione e distruzione da quella di utilizzo.

Qualche esempio: eventi load e close di una finestra, apertura e chiusura di una connessione, acquisizione e rilascio di risorse...

[fek]

Ovviamente io parlo in teoria, non voglio dire che per ogni classe si debba fare questo.
Io esplicitamente lo faccio poche volte, ma è un pattern che si usa implicitamente spessissimo, quando si vogliono separare le fasi di istanziazione e distruzione da quella di utilizzo.

Qualche esempio: eventi load e close di una finestra, apertura e chiusura di una connessione, acquisizione e rilascio di risorse...

Io parlo sia in teoria sia in pratica: separare costruttore e inizializzazione non e' una buona idea se non c'e' un motivo davvero ottimo per farlo, perche' rende l'interfaccia piu' complessa.