Newsgroup: it.comp.lang.c++
Titolo: Eccezioni e costruttori

Ciao a tutti.
Questo messaggio e' sostanzialmente una continuazione del thread "Dove
sta andando il C++ ?". Dal momento che il thread e' uscito
dall'argomento originale, che non avrei saputo a quale messaggio
agganciare il mio e che mi pare comunque si tratti di argomenti
interessanti, ho deciso di avviare un nuovo thread.
Alcune considerazioni:
In generale le eccezioni sono il miglior modo di segnalare il fallimento
della costruzione di un oggetto.
Il C++ marca in modo molto deciso il confine tra un oggetto ed un altro,
sia come layout che come lifetime. Questo lo trovo un positivo stimolo
all'incapsulamento, poiche' permette di garantire che la vita di
un'istanza di una classe inizi quando l'istanza entra in uno stato
consistente, magari costruito sugli stati consistenti raggiunti dai
propri membri dati. Se non e' possibile conseguire questo stato
consistente, non c'e' soluzione migliore al lancio di un'eccezione:
altrimenti tanto vale ritornare a programmare in C con le struct.
Uso di oggetti zombie
Una valida eccezione a quanto ho detto sopra si ha a mio avviso quando
una classe viene utilizzata per modellare e gestire l'interazione con
entita' esterne al programma: il sottosistema di I/O e' un esempio
calzante. In questo caso e' piu' importante star dietro a quello che
succede fuori dal programma che non implementare un modello cristallino
che perde facilmente la sincronizzazione.
Anche la distinzione tra funzionamento corretto ed errore e' facilmente
molto piu' variegata: possono esserci errori transitori, errori
recuperabili, ecc. In questo genere di sizuazioni puo' essere pratico
considerare funzionamento corretto il mantenimento di uno stato interno
consistente da parte dell'istanza, anche in presenza di situazioni
anomale nel mondo circostante.
Eccezioni e costruttore di copia
Confesso di essere anch'io un po' perplesso a proposito delle parole di
Stroustrup. Bisogna pero' considerare che in effetti i costruttori di
copia interagiscono "silenziosamente" con meccanismi di base del
linguaggio (passaggio di parametri, ritorno di valori). Inoltre, se la
semantica della copia e' definita in modo ragionevole, e' un'operazione
che parte da uno stato consistente di un oggetto per crearne un altro
uguale (per una qualche definizione di "uguale"). Mi pare ragionevole
aspettarsi che in queste condizioni un errore di tipo concettuale sia
sostanzialmente un errore di disegno, mentre gli unici errori che e'
ragionevole gestire con eccezioni sono errori catastrofici, come
l'esaurimento della memoria e cose simili. In questo senso il
suggerimento di BS pare ragionevole.
Commenti?
Ciao,
Nicola

suggerimento di BS pare ragionevole.
Io trovo quel suggerimento comunque fuori luogo...
quello che dici e' sensato e non riesco a pensare
a precondizioni strane per un contratto di copia
(tranne che esistono oggetti intrinsecamente non
copiabili... ma questo controllo puo' essere
anticipato a compile-time); questo pero' non dice
nulla di interessante: io credo che la regola "non
lanciare exception tranne che in casi veramente
disastrosi" sia abbastanza generale.
Fra l'altro anche quel termine "catastrofico" e' fumoso.
Catastrofico e' quando non si riesce a mantenere quanto
si e' promesso anche se chi chiede il lavoro ha fornito
tutto quanto era stato chiesto. Questo in generale, la
copia perche' e' cosi' speciale ?
Fra l'altro, il problema dei mitici zombie, l'alternativa
e' tornare comunque un oggetto che pero' non funziona ?
Io direi che *cento* volte meglio e' lanciare una
exception proprio perche' e' assolutamente inusuale
che la copia di un oggetto valido e copiabile non
riesca e *mille* volte meglio perche' vengono fatte
spesso copie in modo abbastanza implicito.
Proprio in questo caso secondo me e' importante urlare
a squarciagola (e non rischiare di far passare la cosa
sotto silenzio, con il chiamante che magari si
dimentica di controllare la riuscita dell'operazione).
Andrea

 Commenti?
CLAP, CLAP, CLAP :-))
ciao Anto
-- 
Antonio Cuni, 19 anni, studente
Brainbench C++ Master: 4.73, higher than 99% of all previous test takers.
C Language: 3.79, higher than 92% of all previous test takers.
Guida C/C++ di Programmazione.it: 
http://cpp.programmazione.it

 dimentica di controllare la riuscita dell'operazione).
In effetti il consiglio andrebbe probabilmente cambiato in qualcosa
tipo: se quando scrivi un costruttore di copia trovi necessario
segnalare un problema con un'eccezione, o stai manipolando una risorsa
esterna (memoria, file, ecc.) o probabilmente il tuo disegno ha qualcosa
che non va.
Ciao,
Nicola

Alcune considerazioni:
[CUT]
Concordo praticamente su tutto.
Il Ghenio
---------
// TODO: Place your ass here