Newsgroup: it.comp.lang.c++
Titolo: eccezioni personalizzate: implementazione migliore

Ciao a tutti.
Siccome devo realizzare una serie di classi da usare come eccezioni
personalizzate (per una libreria che sto scrivendo), chiedo a voi cosa
fareste nel mio caso: scrivereste una classe di eccezione da zero (magari
una classe base da cui derivarne altre più specifiche) oppure derivereste
dalla classe base std::exception?
Lo so che a conti fatti non cambia molto (in effetti std::exception ha una
funzionalità veramente minima), ma vorrei sapere se lo Standard riserva la
classe std::exception per le eccezioni generate dalla STL (e non per quelle
user-defined), e in ogni caso se è bene o male derivare da std::exception
per definire le proprie eccezioni.
Grazie per l'aiuto,
    Marco
--
/*
rimuovi _NOSPAM_ dall'indirizzo email per scrivermi!
*/

 da std::exception per definire le proprie eccezioni.
no, puoi derivare tranquillamente da std::exception. In generale e` 
sempre meglio riutilizzare quello che e` gia` presente la regola vale 
anche in questo caso. Se proprio hai bisogno di funzionalita` 
aggiuntive, deriva una da std::exception una classe che ti servira` da 
classe base, tipo:
class my_exception: public std::exception
{
public:
        virtual void nuova_funzionalita`() = 0;
};
ciao Anto
-- 
Antonio Cuni, 19 anni, studente
Brainbench C++ Master: 4.73, higher than 99% of all previous test takers.
C Language: 3.32, higher than 79% of all previous test takers.
Guida C/C++ di Programmazione.it: 
http://cpp.programmazione.it

user-defined),
No, puoi definire una nuova classe derivandola da std::exception.
Il Ghenio
---------
These are my parting words to you:
those who give up are doomed!

precisamente quale eccezione sia stata generata) 
Sicuro che sia proprio la scelta giusta? Intendo... se le eccezioni lanciate
nella tua libreria hanno qualcosa a che fare con quelle standard... allora si
puo' valutare il caso di derivare una gerarchia di eccezioni da std::exception,
ma... tu proponi di lanciare un'eccezione di tipo base std::exception,
intercettarla con un bel catch(std::exception), poi identificarne il tipo
all'interno del blocco catch e regolarti in modo diverso a seconda del tipo
effettivo dell'eccezione. A questo punto non sarebbe molto piu' pulito,
elegante e soprattutto efficiente intercettare eccezioni non troppo correlate
tra di loro, con piu' blocchi catch? Io ho sempre fatto cosi' e non mi sono mai
trovato male, almeno nella gestione degli errori :-)
Ciao
Domenico
-- 
Domenico Barra, Brainbench C++ Master
ba...@programmazione.it
domb...@studenti.unina.it
dob...@iol.it

trovato male, almeno nella gestione degli errori :-)
Potrebbe esserlo, ma secondo me in questo caso non converrebbe
derivare da std::exception, sarebbe molto meglio creare una gerarchia
di classi autonoma e gestirla separatamente dalle eccezioni generate
dal linguaggio e dalla libreria standard.
Il Ghenio
---------
// TODO: Place your ass here

dal linguaggio e dalla libreria standard.
Esatto, e secondo me nella maggior parte dei casi e' la scelta migliore, anche
perche' le eccezioni "personalizzate" poco hanno a che fare con le eccezioni
"std" (standard).


catch(...) { } // discutibile!
Se devi catturare una exception sinifica che spesso
devi "rimettere a posto qualcosa" nel caso che nel
codice protetto si verifichi un problema. Se hai piu'
di una catch allora questo "rimettere a posto" dovra'
essere ripetuto nei vari casi ?
Andrea

Efficienza ed exception non sono termini molto compatibili.
Le exception sono un sistema che va saputo usare, ed in questo caso
non va a discapito delle prestazioni ma aiuta a scrivere codice più
sicuro e molto più pulito di quanto non si possa fare con i codici di
ritorno delle funzioni e gli errno.
Forse un programma di 1000 righe può essere scritto anche inserendo un
codice di ritorno per ogni funzione , ma nei progetti grossi questo é
assolutamente impensabile, visto che alla fine si é costretti e dover
scrivere codice ovunque per far si che un errore si propaghi fino alla
funzione chiamata, ed anche una sola svista o un codice di ritorno non
considerato può compromettere la sicurezza del programma.
Con le eccezioni tutto ciò non accade perché il meccanismo di
propagazione é automatico.
Mi é capitato di recente di scrivere un programma che generava frasi
di senso compiuto utilizzando un vocabolario letto da un file,
l'algoritmo era basato su due exception handler, uno interno alle
funzioni membro della classe che generava le frasi ed un altro esterno
che esauriti i tentativi si incaricava di segnalare gli errori
all'interfaccia grafica.
L'uso delle exception mi ha consentito di non sovraccaricare il
programma con valori di ritorno delle funzioni e la sicurezza che
qualsiasi errore venga gestito, tanto per fare una prova ho tolto le
eccezioni sostituendole con un altro sistema di gestione degli errori
e non ho guadagnato neanche un picosecondo in prestazioni.


 equivalente a *decine di migliaia* di chiamate a funzione.
Le eccezioni sono pensate per gestire casi patologici in cui il
software e' nell'impossibilita' di seguire il suo corso per la
mancanza di informazioni fondamentali o la presenza di condizioni
esterne eccezionali (come un file system non montato, la mancanza di
un collegamento alla rete TCP/IP o simili).
Ti aspetti forse di lanciare e catturare eccezioni qualche centinaio
di volte?  Cosa ti importa del rapporto tra il tempo impiegato da un
try/throw/catch e le chiamate a funzione?
L'uso _giudizioso_ delle eccezioni rende un programma piu' sicuro e
leggibile; e questo e' quello che conta.
-- 
Maurizio Loreti  - Linux Is Not UniX -  
http://www.pd.infn.it/~loreti/mlo.html
Univ. of Padova, Dept. of Physics - Padova, Italy            
lor...@pd.infn.it

 leggibile; e questo e' quello che conta.
Il nostro Andrea, da quello che mi sembra aver capito, fa a
cazzoti quando scrive i programmi per recuperare l'ultimo
millesimo di secondo e l'ultimo byte visto che ha
a che fare con sistemi "Real Time Embedded". Ecco il perche'.
Ciao
Gaetano
--
#exclude <windows>
printf("\t\t\b\b\b\b\b\b");.
printf("\t\t\b\b\b\b\b\b");

essere ripetuto nei vari casi ?
Si tratta di "studiare" come vanno posti gli exception handlers... spesso
(anzi, direi quasi sempre) in C la condizione di errore viene controllata ogni
volta che si vuole tramite il valore restituito da una data funzione... cosi'
facendo si mischia codice operativo e codice eccezionale, e a mio parere
questo, piu' che le eccezioni, potrebbe favorire una qualche complicazione
logica. Con le eccezioni hai tutto (o quasi) il codice per la gestione degli
errori "critici" separato dal codice operativo, in modo da avere una chiarezza
senza dubbio migliore in fase di lettura, e per riflesso una manutenibilita'
piu' elevata. Se si deve semplicemente "rimettere a posto qualcosa in tutti i
casi" allora basta "catch"are l'eccezione di tipo base, eseguire il cleanup e
basta, comunque ci sarebbe molto da parlare sui metodi di cleanup... Si parlava
invece di assumere un comportamento diverso a seconda del tipo dell'eccezione
intercettata, e qui io resto del parere che un metodo come quello suesposto sia
migliore di un "catchall" con switch interno.
Ciao :-)


try/throw/catch e le chiamate a funzione?
Forse il senso del mio messaggio e' stato frainteso: io
intendevo dire *esattamente* quello che stai dicendo.
Se uno si preoccupa delle *prestazioni* di avere piu'
catch secondo me c'e' qualcosa che non va. Significa cioe'
che si stanno usando exception per cose che non hanno
nulla di eccezionale.
Andrea

a che fare con sistemi "Real Time Embedded". Ecco il perche'.
Io penso che scrivere un programma preoccupandosi anzitempo delle
prestazioni di ogni singola parte di codice porti facilmente
all'improduttività. Quando si scrive un software occorre trovare la
soluzione migliore, più sicura, più manutenibile, provare il prodotto
ed al limite se ci si accorge che le prestazioni non sono quelle che
si desideravano intervenire.
Nella maggior parte dei casi l'1% del codice é responsabile della
perdita di prestazioni di un intero programma.
Tornando al discorso eccezioni, bisogna dire che ci sono settori nei
quali la gestione degli errori può essere fatta in maniera normale (
codice di ritorno delle funzioni, ecc..ecc..) senza particolari
problemi, altri in cui poter sentenziare alcuni eventi tramite il
lancio di particolari eccezioni é una manna dal cielo, specie se si
sta progettando una libreria e non si vuole che chi la usi sia
costretto in ogni parte del programma a chiamare la funzione che ti
dice che non si può proseguire perché é avvenuto qualcosa(penso ad
esempio alla disconnessione di un telefono). E' chiaro che la gestione
delle eccezioni deve essere fatta in modo intelligente, cospargere
ogni funzione di exception-handler é una soluzione pessima, se il
software é ben progettato ne possono bastare pochissimi posizionati
nei punti strategici.


 perdita di prestazioni di un intero programma.
Esagerato. Ricordiamo sempre la regola 80/20
Cioe' 80 % del tempo perso nel 20% del codice.
--


 il progetto non e' fattibile.
Senza contare che l'invito a non ottimizzare prematuramente non esime
dallo scegliere algoritmi e costrutti con buon senso!
Ciao,
Nicola

dallo scegliere algoritmi e costrutti con buon senso!
Questo era ovvio.
