Newsgroup: it.comp.lang.c++
Titolo: Gestione eccezioni

Il C++ soffre del difetto che non obbliga a dichiarare e gestire le 
eccezioni di una chiamata (a differenza di Java).
Quindi, per essere sicuri di gestire tutte le eccezioni previste in una 
libreria di terze parti, fare una macro che le gestisca una ad una ed usarla 
ad ogni chiamata a quella libreria, e' una grossa cazzata in termini di 
efficienza oppure no ?
Ludo.

 efficienza oppure no ?
No, e' una "cazzata" e basta. Le gestioni andrebbero gestite con
cognizione di causa, non tanto per fare. Tra l'altro potendo comunque
usare 'catch (...)' non vedo a cosa possa servire la tua macro.
Per essere sicuro di gestire tutte le eccezioni lanciate da una
libreria consulta la documentazione e testa il tuo codice.
Ciao,
Nicola

 consulta la documentazione e testa il tuo codice.
Sono d'accordo con te, se ci fosse il tempo di farlo... :-(((( Comunque io 
non mi fiderei troppo nemmeno della documentazione.
Ludo.

 macro, ma e' troppo lungo da spiegare.
Porcheria per porcheria una soluzione che potrebbe funzionare, ma che
va usata con cutela e' scrivere una funzione cosi':
#include <iostream>
#include <ostream>
struct e1 {};
struct e2 {};
struct e3 {};
void catch_all() {
  try {
    throw;
  }
  catch ( e1 & ) {
    std::cout << "e1\n";
  }
  catch ( e2 & ) {
    std::cout << "e2\n";
  }
  catch ( ... ) {
    std::cout << "sconosciuta\n";
  }
}
Questa va chiamata *solo ed esclusivamente* dall'interno di una
clausola 'catch (...)', come in questo esempio:
int main() {
  for ( int i = 0; i < 3; ++i ) {
    try {
      switch(i) {
        case 0:
	  throw e1();
	case 1:
	  throw e2();
	case 2:
	  throw e3();
      }
    }
    catch(...) {
      catch_all();
    }
  }
}
Se ci tieni alla macro puoi sempre fare qualcosa come:
#define CATCH_ALL catch(...) { catch_all(); }
Ciao,
Nicola

> una soluzione che potrebbe funzionare
Si', ho capito, come la mia, ma a due livelli: interessante, la provero'.
Grazie !!! :-)
Ludo.

 non mi fiderei troppo nemmeno della documentazione.
Sigh.
-- 
blog:  
http://www.akropolix.net/rik0/blogs
 | Uccidete i filosofi,
site:  
http://www.akropolix.net/rik0/
      | tenetevi riso e
forum: 
http://www.akropolix.net/forum/
     | bacchette per voi.

> Se non ti fidi licenziali.
E questo cosa vuol dire ? Possono scordarsi di gestire qualche eccezione, ma 
possono avere anche delle qualita' non strettamente connesse alla 
programmazione, tipo attitudine al problem-solving, capacita' di disegnare 
delle UI coerenti, etc... I miei programmatori partecipano anche al design, 
e ci tengo che sia cosi', perche' e' giusto che si rendano conto dei 
problemi reali del software sul campo, quando deve essere usato dagli 
ut(o)nti. Ogni tanto (raramente), qualcuno di loro lo mando anche ad 
installare dal cliente, cosi' capiscono che cosa si trovano ad affrontare i 
poveri sistemisti.
Pensi che i programmatori si possano sostituire dall'oggi al domani 
schioccando le dita ? Dopo che li hai formati, dopo che conoscono il sistema 
che loro stessi hanno sviluppato ? Guarda che hanno lavorato per me 
dedicando anni della loro vita all'azienda, quindi i problemi, se ci sono, 
si risolvono in ben altro modo che minacciando licenziamenti in tronco.
Dici di vivere nel mondo dei competenti, ma sai benissimo che e' un'utopia, 
sia dalla parte dei dipendenti che da quella dei datori di lavoro. E non mi 
venire a parlare della flessibilita' americana / svizzera / giapponese, 
perche' anche loro hanno i loro bei casini ad andare avanti. Puoi essere 
competente al 150% su una tecnologia, ma il giorno dopo ne arriva una nuova 
e devi ricominciare daccapo (per sfiga o per fortuna).
Salumi,
Ludo.

 e devi ricominciare daccapo (per sfiga o per fortuna).
Tu dici che vuoi la gestione forzata delle eccezioni perchè se no loro
sbagliano. "Vatti a fidare tu dei miei programmatori senza controllare
il codice che scrivono."
Questo peraltro sottointende che o avete una sezione di test che
giudicate limitata, di cui non vi fidate, oppure testate "late" (cosa
che non va bene, peraltro).
Non sono io che ho detto che i tuoi programmatori sono inaffidabili. Lo
hai scritto tu. Il punto non è un licenziamento "punitivo": il punto è
che tu non ti fidi di loro. Si vive malissimo in un ambiente dove manca
la fiducia.
Quindi o loro non se la meritano (e se hanno altre skill buon per loro,
ma ti conviene fare programmare da gente di cui ti fidi), oppure sei tu
che non vuoi fidarti (e questo di sicuro non aiuta). In questo senso il
mio consiglio.
Ribadisco se un sistema per gestire le eccezioni fa la differenza,
allora occhio: qualcosa non va nel sistema produttivo. Troppi pochi
test, oppure hai ragione tu e non ti puoi fidare dei programmatori (ma
io da un medico di cui non mi fido non ci vado, manco se ci sono andato
per 20 anni prima, quando mi fidavo).
Oppure è semplicemente una "mania" tua: i programmatori sono abili e il
processo produttivo funzionante. Bene, allora dai loro la fiducia che
meritano.
