Torna indietro   Hardware Upgrade Forum > Software > Programmazione

Intervista a Stop Killing Games: distruggere videogiochi è come bruciare la musica di Mozart
Intervista a Stop Killing Games: distruggere videogiochi è come bruciare la musica di Mozart
Mentre Ubisoft vorrebbe chiedere agli utenti, all'occorrenza, di distruggere perfino le copie fisiche dei propri giochi, il movimento Stop Killing Games si sta battendo per preservare quella che l'Unione Europea ha già riconosciuto come una forma d'arte. Abbiamo avuto modo di parlare con Daniel Ondruska, portavoce dell'Iniziativa Europa volta a preservare la conservazione dei videogiochi
Samsung Galaxy S25 Edge: il top di gamma ultrasottile e leggerissimo. La recensione
Samsung Galaxy S25 Edge: il top di gamma ultrasottile e leggerissimo. La recensione
Abbiamo provato il nuovo Galaxy S25 Edge, uno smartphone unico per il suo spessore di soli 5,8 mm e un peso super piuma. Parliamo di un device che ha pro e contro, ma sicuramente si differenzia dalla massa per la sua portabilità, ma non senza qualche compromesso. Ecco la nostra prova completa.
HP Elitebook Ultra G1i 14 è il notebook compatto, potente e robusto
HP Elitebook Ultra G1i 14 è il notebook compatto, potente e robusto
Pensato per il professionista sempre in movimento, HP Elitebook Ultra G1i 14 abbina una piattaforma Intel Core Ultra 7 ad una costruzione robusta, riuscendo a mantenere un peso contenuto e una facile trasportabilità. Ottime prestazioni per gli ambiti di produttività personale con un'autonomia lontano dalla presa di corrente che permette di lavorare per tutta la giornata
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 17-03-2010, 18:27   #1
mcaisco
Member
 
Iscritto dal: Jun 2006
Messaggi: 117
[ALL] Curiosita' sui flusso di controllo di un programma

Scusate, spesso mi imbatto in situazioni in cui devo eseguire una serie di operazioni all'interno di un "task" piu' generale e spesso l'operazione i-esima deve essere eseguita solo se la precedente e' andata a buon fine.

Per esempio ho un task generico che per coerenza logica e' suddiviso in 4 operazioni A, B, C e D. Ogni operazione e' ovviamente una funzione.
Ad esempio:
- A = lettura di un file con i dati di connessione
- B = connessione ad un db
- C = esecuzione select
- D = lettura recordset ottenuto

Ognuna di queste 4 operazioni dipende dal successo della precedente (vabbe' a parte la prima che va sempre eseguita...).

Sinceramente a me fa abbastanza schifo scrivere codice del tipo:
Codice:
if(A)
   if(B)
      if(C)
         if(D) ...
         else errore D
      else errore C
   else errore B
else errore A
Anche perche' non sempre le cose sono cosi' lineari.

Vorrei sapere se voi seguite degli schemi precisi o meno. Questa e' una questione piuttosto sottovalutata in programmazione ma alla fine la "ciccia" dei nostri programmi e' proprio costituita da tutti quei brutti IF, SWITCH, WHILE, FOR... di cui anche la programmazione ad oggetti prima o poi necessita.
mcaisco è offline   Rispondi citando il messaggio o parte di esso
Old 17-03-2010, 18:30   #2
wingman87
Senior Member
 
Iscritto dal: Nov 2005
Messaggi: 2774
Con il meccanismo delle eccezioni (se disponibile) puoi scrivere codice più elegante e leggibile:

Codice:
try{
  A
  B
  C
  D
}catch(Errore){
  Gestione Errore
}
wingman87 è offline   Rispondi citando il messaggio o parte di esso
Old 17-03-2010, 18:38   #3
mcaisco
Member
 
Iscritto dal: Jun 2006
Messaggi: 117
Beh non e' necessariamente corretto e produttivo l'uso delle eccezioni per la gestione degli errori. Le eccezioni generalmente vanno lanciate e catturate per gestire situazioni "eccezionali" appunto, cioe' imprevisti.

Nelle situazioni a cui faccio riferimento, come nell'esempio, io vorrei che B venisse eseguita solo se A va a buon fine, ma A potrebbe benissimo ritornare errore per un motivo piu' che lecito e per nulla "eccezionale". Cioe' non sempre le operazioni falliscono per motivi inconsueti.
Per esempio l'operazione C dell'esempio (select su db) potrebbe semplicemente ritornare null perche' non trova alcun record, ma questo non significa che si debba lanciare un'eccezione!

Per chiarire meglio, il mio codice nel caso presentato e' spesso cosi:
Codice:
try
{
   if(A)
      if(B)
         if(C)
            if(D) ...
            else errore D
         else errore C
      else errore B
   else errore A
}catch(Errore){
  Gestione Errore
}
Cioe' le operazioni sonno "immerse" quasi sempre in un try-catch in modo da poter gestire situazioni impreviste. Ma le operazioni possono fallire per situazioni prevedibilissime che nulla hanno a che fare con le eccezioni.
mcaisco è offline   Rispondi citando il messaggio o parte di esso
Old 17-03-2010, 18:53   #4
WarDuck
Senior Member
 
L'Avatar di WarDuck
 
Iscritto dal: May 2001
Messaggi: 12815
Mah non saprei... è prevedibile che un sistema di risoluzione dei nomi (tipo DNS) possa non trovare alcun record relativo ad un URL?

A mio parere si, eppure nei moderni linguaggi di programmazione questa viene considerata una eccezione.

La regola è che tutto funzioni come dovrebbe, l'eccezione è proprio un caso che non ti consente di andare avanti nel programma di per se.

Nel tuo caso:

- A = lettura di un file con i dati di connessione
- B = connessione ad un db
- C = esecuzione select
- D = lettura recordset ottenuto

A e B possono essere tranquillamente gestite tramite eccezioni.

In C l'esecuzione della select per quale motivo dovrebbe fallire, supponendo che la query sia pre-confezionata e ben formata?

Stessa cosa per D, NULL non è un fallimento.

Qui il piano si sposta su cosa consideri come fallimento... supponendo che per C e D valgano le mie considerazioni, non ci sarebbe alcun motivo di fare un controllo su queste due cose.

Chiaramente in fase di presentazione dei risultati il discorso è diverso, in quanto eventuali record NULL potresti volerli evitare (adesso non ricordo se i ResultSet scartano in automatico i record NULL, in quel caso non dovresti fare controlli, in genere le routine di presentazione ciclano sulla base della dimensione del ResultSet, che in questo caso sarebbe nulla).

E' chiaro che questo è un esempio, come dici te ci si può trovare spesso nella situazione di dover effettuare più controlli concatenati, e se non vuoi ricorrere alle eccezioni credo che quello sia l'unico modo.

Una cosa che ho trovato comoda per levare un po' di if di mezzo è usare ove possibile il polimorfismo, chiaramente non si può usare sempre questa via (ad esempio in questo caso poco c'entrerebbe), però in alcuni casi può essere la soluzione.

Ultima modifica di WarDuck : 17-03-2010 alle 18:58.
WarDuck è offline   Rispondi citando il messaggio o parte di esso
Old 17-03-2010, 19:25   #5
PGI-Bis
Senior Member
 
L'Avatar di PGI-Bis
 
Iscritto dal: Nov 2004
Città: Tra Verona e Mantova
Messaggi: 4553
Se usi un linguaggio OO la questione non si pone. Ogni linguaggio orientato agli oggetti è un meta-linguaggio. Significa tra l'altro che sei sempre libero di definire un approccio alla soluzione di un problema che esula dalle operazioni predefinite.

Bisogna avere un'idea alternativa, un "sarebbe bello se potessi scrivere così".

Come si potrebbe esprimere una catena di if in modo non annidato? Si potrebbe usare un concatenatore di espressioni, qualcosa cioè che data una lista di espressioni esegua la successiva solo se la precedente abbia dato un certo risultato. Diremmo allora:

a = if x qualcosa else qualcos'altro
b = if x qualcosa else qualcos'altro
...
z = if x qualcosa else qualcos'altro
concatenatore esegui a + b + ... + z

Non è difficile pensare a come si possa realizzare. Abbiamo semplicemente un'espressione composta di una condizione e due alternative che restituisce un valore di controllo, diciamo un booleano. L'espressione restituisce true se la condizione è true altrimenti esegue l'alternativa e restituisce false. Il concatenatore piglia queste espressioni e dice:

per ogni espressione x se x.eval restituisce true esegui la successiva altrimenti termina.

Tutto sta nello scegliere una soluzione: il resto lo fa l'orientamento agli oggetti.
__________________
Uilliam Scecspir ti fa un baffo? Gioffri Cioser era uno straccione? E allora blogga anche tu, in inglese come me!
PGI-Bis è offline   Rispondi citando il messaggio o parte di esso
Old 17-03-2010, 19:49   #6
sadino90
Junior Member
 
Iscritto dal: Mar 2010
Messaggi: 8
Non basta definire un metodo per A che ritorna un valore booleano per indicarne l'esito?
Così puoi tranquillamente scrivere
Codice:
if(A)
  B
E come dice WarDuck per C e D non occorrono controlli

Ultima modifica di sadino90 : 17-03-2010 alle 19:56.
sadino90 è offline   Rispondi citando il messaggio o parte di esso
Old 17-03-2010, 20:48   #7
cionci
Senior Member
 
L'Avatar di cionci
 
Iscritto dal: Apr 2000
Città: Vicino a Montecatini(Pistoia) Moto:Kawasaki Ninja ZX-9R Scudetti: 29
Messaggi: 53971
Quote:
Originariamente inviato da mcaisco Guarda i messaggi
Beh non e' necessariamente corretto e produttivo l'uso delle eccezioni per la gestione degli errori. Le eccezioni generalmente vanno lanciate e catturate per gestire situazioni "eccezionali" appunto, cioe' imprevisti.
Direi di no. Le eccezioni servono proprio per la gestione degli errori.
Le situazioni "eccezionali" sono invece quelle non previste e quindi non gestite se non, solitamente, da un try catch in cui è contenuto il ciclo principale del programma. Java differenzia proprio bene questa situazione con le checked e le unchecked exception.
cionci è offline   Rispondi citando il messaggio o parte di esso
Old 18-03-2010, 08:37   #8
mcaisco
Member
 
Iscritto dal: Jun 2006
Messaggi: 117
Beh veramente tutto quello che ho letto sulle eccezioni generalmente diceva proprio di evitare di utilizzare le eccezioni per la gestione degli errori comuni e prevedibili.

In ogni caso non volevo focalizzarmi su un esempio preciso, ma piuttosto su una "best practice" comune. E' innegabile infatti che generalmente un sistema software complesso presenta innumerevoli operazioni composte da altre operazioni e cosi' via, creando un annidamento non banale.
Proprio per questo generalmente le best practice per l'exception handling dicono di gestire le eccezioni il piu' vicino possibile al punto in cui vengono generate.
Questo implica chiaramente che non si puo' utilizzare un unico try-catch a livello del main, ma invece occorre avere un blocco try-catch quasi in ogni metodo-operazione sufficientemente complessa da poter generare molte situazioni anomale e impreviste.
E questo e' un altro punto fondametale. Infatti gran parte delle funzioni-metodi corposi a mio parere devono avere una gestione moltro stretta degli errori, cioe' gestire tutto il piu' localmente possibile e soprattutto bisogna sempre supporre che per quanto siamo stati bravi, potrebbe essere generato un errore imprevisto anche dopo mesi che il software e' in stato di release.

Nell'esempio che ho fatto, volutamente semplice, vorrei farvi notare che, sì, e' vero che una semplice select difficilmente fallisce, ma ripeto, volevo cercare di rendere l'idea con un piccolo esempio, non focalizzarmi su quello. In una situazione reale qulle operazioni A-B-C-D magari al loro interno sono molto piu' complesse e a loro volta sono suddivise in sotto-operazioni, anch'esse da eseguirsi in sequenza una dopo l'altra.
E' innegabile quindi che non e' possibile fare in modo che qualunque metodo in caso di errore lanci un'eccezione piuttosto che gestire localmente l'errore. Questo puo' essere corretto solo per pochi casi isolati, ma in genere, questo sistema di "scarica barile" sul chiamante prima o poi deve terminare con un try-catch piu' generale, e se tutti i metodi fanno lo scarica barile... l'unico try-catch che gestisce tutto e' sul main... e quello poverino non ne sa piu' nulla dell'errore e non fa altro che dire "HEY.. ERRORE!". E tanti saluti.
mcaisco è offline   Rispondi citando il messaggio o parte di esso
Old 18-03-2010, 13:19   #9
fero86
Senior Member
 
Iscritto dal: Oct 2006
Città: Roma
Messaggi: 1383
scusate, non leggo il thread ma do ugualmente la mia risposta.



Quote:
Originariamente inviato da mcaisco Guarda i messaggi
Ognuna di queste 4 operazioni dipende dal successo della precedente (vabbe' a parte la prima che va sempre eseguita...).

Sinceramente a me fa abbastanza schifo scrivere codice del tipo:
Codice:
if(A)
   if(B)
      if(C)
         if(D) ...
         else errore D
      else errore C
   else errore B
else errore A
Anche perche' non sempre le cose sono cosi' lineari.

Vorrei sapere se voi seguite degli schemi precisi o meno. Questa e' una questione piuttosto sottovalutata in programmazione ma alla fine la "ciccia" dei nostri programmi e' proprio costituita da tutti quei brutti IF, SWITCH, WHILE, FOR... di cui anche la programmazione ad oggetti prima o poi necessita.
questione interessantissima: mi ci sono imbattuto anche io qualche anno fa e ho trovato la miglior soluzione nel design pattern degli scoped objects del C++. quando dichiari variabili automatiche in uno scope, lo standard del C++ garantisce che i distruttori verranno invocati in ordine inverso rispetto all'ordine di dichiarazione (e quindi inverso rispetto all'ordine di invocazione dei costruttori), il che ti permette ad esempio di tradurrre questo codice:
Codice:
if (inizializzazione di A riuscita con successo) {
	if (inizializzazione di B riuscita con successo) {
		if (inizializzazione di C riuscita con successo) {
			esegui operazione che usa A, B e C;
			cleanup di C;
		} else {
			errore relativo a C;
		}
		cleanup di B;
	} else {
		errore relativo a B;
	}
	cleanup di A;
} else {
	errore relativo ad A;
}
in questo, molto migliore IMO:
Codice:
class A {
public:
	A() {
		if (inizializzazione di A fallisce) {
			throw false;
		}
	}

	~A() {
		cleanup di A;
	}
};

class B {
public:
	B() {
		if (inizializzazione di B fallisce) {
			throw false;
		}
	}

	~B() {
		cleanup di B;
	}
};

class C {
public:
	C() {
		if (inizializzazione di C fallisce) {
			throw false;
		}
	}

	~C() {
		cleanup di C;
	}
};

{
	A a;
	B b;
	C c;
	esegui operazione che usa a, b e c;
}
fero86 è offline   Rispondi citando il messaggio o parte di esso
Old 18-03-2010, 14:28   #10
cionci
Senior Member
 
L'Avatar di cionci
 
Iscritto dal: Apr 2000
Città: Vicino a Montecatini(Pistoia) Moto:Kawasaki Ninja ZX-9R Scudetti: 29
Messaggi: 53971
Quote:
Originariamente inviato da mcaisco Guarda i messaggi
Beh veramente tutto quello che ho letto sulle eccezioni generalmente diceva proprio di evitare di utilizzare le eccezioni per la gestione degli errori comuni e prevedibili.
Java non la pensa così: http://java.sun.com/javase/6/docs/ap...va.lang.String)
Quello è uno dei casi da te proposti
Poi dipende sempre cosa si intende per "situazione eccezionale". Secondo me le eccezioni vanno usate in tutti i casi in cui la mancata esecuzione di una operazione abbia implicazioni nel proseguimento di una sequenza di operazioni che si suppone il chiamante esegua. L'esempio della connessione al database è proprio una di queste.
Altrimenti uso la normale gestione degli errori con il ritorno di boolean.

Comunque le possibilità possono essere molteplici, dipende molto anche da chi programma le varie operazioni. Se lo facessi io penserei ad una classe con le varie operazioni di ripulitura...

Che so, una cosa del genere:
Codice:
UndoInfo undo;

bool doSomething(...., UndoInfo &undo)
{
   if(!x.a(..., undo))
   {
      return false;
   }
   if(!x.b(..., undo))
   {
      return false;
   }
   if(!x.c(..., undo))
   {
      return false;
   }

   return x.d(..., undo));
}

UndoInfo undo;
if(!doSomething(...., undo))
{
   undo.cleanUp();
}
Se uno vuole fare il figo (anche se si perde in leggibilità):

Codice:
bool doSomething(...., UndoInfo &undo)
{
   return x.a(..., undo) && (x.b(..., undo) && x.c(..., undo) && x.d(..., undo));
}
Ogni operazione su x aggiungerà le relative operazioni di clenup ad UndoInfo. Il modo in cui si possono aggiungere dipende molto dal linguaggio:
- per linguaggi interpretati si aggiungeranno stringhe che poi verranno interpretate con la relativa funzione eval
- per altri linguaggi si dovrà implementare un'interfaccia ed inserire il method object all'interno di UndoInfo.

UndoInfo::cleanUp non dovrà fare altro che eseguire in ordine inverso rispetto all'inserimento le varie operazioni di clean up

Ultima modifica di cionci : 18-03-2010 alle 14:37.
cionci è offline   Rispondi citando il messaggio o parte di esso
Old 18-03-2010, 14:42   #11
cionci
Senior Member
 
L'Avatar di cionci
 
Iscritto dal: Apr 2000
Città: Vicino a Montecatini(Pistoia) Moto:Kawasaki Ninja ZX-9R Scudetti: 29
Messaggi: 53971
Quote:
Originariamente inviato da fero86 Guarda i messaggi
Codice:
class A {
public:
	A() {
		if (inizializzazione di A fallisce) {
			throw false;
		}
	}

	~A() {
		cleanup di A;
	}
};

class B {
public:
	B() {
		if (inizializzazione di B fallisce) {
			throw false;
		}
	}

	~B() {
		cleanup di B;
	}
};

class C {
public:
	C() {
		if (inizializzazione di C fallisce) {
			throw false;
		}
	}

	~C() {
		cleanup di C;
	}
};

{
	A a;
	B b;
	C c;
	esegui operazione che usa a, b e c;
}
Sicuramente ha senso, però io tendo a fare generalmente costruttori passivi, che si limitino esclusivamente ad inizializzare le variabili membro. Questo per vari motivi:
- i costruttori si debuggano peggio
- mi piace vedere invocato un metodo che descriva l'esatta operazione che sto facendo
cionci è offline   Rispondi citando il messaggio o parte di esso
Old 18-03-2010, 16:59   #12
fero86
Senior Member
 
Iscritto dal: Oct 2006
Città: Roma
Messaggi: 1383
Quote:
Originariamente inviato da cionci Guarda i messaggi
- i costruttori si debuggano peggio
perché? io non ho mai incontrato simili difficoltá, se faccio step into il debugger mi entra regolarmente nel costruttore prima di proseguire e se metto un breakpoint nel costruttore il debugger mi ci si ferma regolarmente.

edit - parlo del debugger di Visual C++



Quote:
- mi piace vedere invocato un metodo che descriva l'esatta operazione che sto facendo
gusti, a me va bene anche vedere le tre dichiarazioni tenendo presente la semantica del C++.
anzi, di un linguaggio mi piace sfruttare tutti i meccanismi.
fero86 è offline   Rispondi citando il messaggio o parte di esso
Old 18-03-2010, 17:50   #13
cionci
Senior Member
 
L'Avatar di cionci
 
Iscritto dal: Apr 2000
Città: Vicino a Montecatini(Pistoia) Moto:Kawasaki Ninja ZX-9R Scudetti: 29
Messaggi: 53971
Quote:
Originariamente inviato da fero86 Guarda i messaggi
perché? io non ho mai incontrato simili difficoltá, se faccio step into il debugger mi entra regolarmente nel costruttore prima di proseguire e se metto un breakpoint nel costruttore il debugger mi ci si ferma regolarmente.

edit - parlo del debugger di Visual C++
Sì, anche gdb ci entra, ma a volte la cosa produce alcuni effetti collaterali antipatici.
Succede a volte, ma non voglio rischiare...
Quote:
Originariamente inviato da fero86 Guarda i messaggi
gusti, a me va bene anche vedere le tre dichiarazioni tenendo presente la semantica del C++.
anzi, di un linguaggio mi piace sfruttare tutti i meccanismi.
Sì, però se guardi alla definizione di costruttore, soprattutto quello di default, in teoria si dovrebbe limitare a "costruire" la classe. Eventuali funzionalità sono insite nei costruttori specializzati, che poi, solitamente, non fanno altri che andare a richiamare un metodo della stessa classe.
Di esempi ce ne sono a bizzeffe, ma anche se si va a vedere il pattern Method Object (cioè un oggetto con un solo metodo), l'implementazione non è mai nel costruttore, ma anche per ovvi motivi: non potrei passare l'oggetto per valore perché eseguirei due volte l'operazione, oppure eseguirei l'operazione quando non mi serve.

Ultima modifica di cionci : 18-03-2010 alle 17:56.
cionci è offline   Rispondi citando il messaggio o parte di esso
Old 18-03-2010, 19:28   #14
tomminno
Senior Member
 
Iscritto dal: Oct 2005
Messaggi: 3306
Quote:
Originariamente inviato da fero86 Guarda i messaggi
in questo, molto migliore IMO:
Codice:
class A {
public:
	A() {
		if (inizializzazione di A fallisce) {
			throw false;
		}
	}

	~A() {
		cleanup di A;
	}
};

class B {
public:
	B() {
		if (inizializzazione di B fallisce) {
			throw false;
		}
	}

	~B() {
		cleanup di B;
	}
};

class C {
public:
	C() {
		if (inizializzazione di C fallisce) {
			throw false;
		}
	}

	~C() {
		cleanup di C;
	}
};

{
	A a;
	B b;
	C c;
	esegui operazione che usa a, b e c;
}
Mi dispiace deluderti ma se gli scoped object rappresentano (o dovrebbero esserlo) una pratica comune in C++, un costruttore che solleva eccezioni invece non lo è, e anzi è altamente sconsigliato.
Ovviamente non sono io a dirlo ma un certo Herb Sutter http://www.gotw.ca/gotw/066.htm di cui consiglio: Exceptional C++ e More Exceptional C++.

Il primo risultato è che non verrà mai chiamato il distruttore in quanto l'oggetto ha vita solo alla fine del costruttore ma se questo solleva un'eccezione non termina correttamente.
Un costruttore che solleva eccezioni ti porta ad usare i function try block in altre classi. I function try block sono obbligati a risollevare un'eccezione quindi ciò comporta che rischi di non portare a termine la costruzione di un'intera collezione di oggetti, nell'esempio tutte le classi che abbiano come variabile d'istanza un oggetto di tipo A o B o C e così ricorsivamente.
Ovvero rischi di ritrovarti al catch nel main:
Codice:
class ThrowChild 
{
public:
	ThrowChild() 
	{ 
	throw exception("faccio terminare il programma");
	}
};

class NoThrowChild
{
public:
	NoThrowChild() try :tc(){}catch(...){throw exception("Houston abbiamo un problema"); }
private:
	ThrowChild tc;
};

class MainNoThrow
{
public:
	MainNoThrow() {}
private:
	NoThrowChild ntc;
};

int main(int argc, char *argv[])
{
	try
	{
		MainNoThrow nt;
	}
	catch(const exception & ex)
	{
		cout << ex.what() << endl;
		exit(-1);
	}
	catch(...)
	{
		exit(-1);
	}
	return 0;
}
tomminno è offline   Rispondi citando il messaggio o parte di esso
Old 18-03-2010, 20:40   #15
PGI-Bis
Senior Member
 
L'Avatar di PGI-Bis
 
Iscritto dal: Nov 2004
Città: Tra Verona e Mantova
Messaggi: 4553
Quote:
Originariamente inviato da tomminno Guarda i messaggi
di cui consiglio: Exceptional C++ e More Exceptional C++.
Caspita, 'sto tizio è proprio stupefatto da C++. Il terzo volume come l'ha chiamato? C++ ecceziunale veramente?
__________________
Uilliam Scecspir ti fa un baffo? Gioffri Cioser era uno straccione? E allora blogga anche tu, in inglese come me!
PGI-Bis è offline   Rispondi citando il messaggio o parte di esso
Old 18-03-2010, 21:20   #16
rеpne scasb
Senior Member
 
Iscritto dal: May 2008
Messaggi: 533

Ultima modifica di rеpne scasb : 18-06-2012 alle 15:59.
rеpne scasb è offline   Rispondi citando il messaggio o parte di esso
Old 18-03-2010, 21:59   #17
tomminno
Senior Member
 
Iscritto dal: Oct 2005
Messaggi: 3306
Quote:
Originariamente inviato da PGI-Bis Guarda i messaggi
Caspita, 'sto tizio è proprio stupefatto da C++. Il terzo volume come l'ha chiamato? C++ ecceziunale veramente?
Exceptional C++ Style
Questo "tizio" è stato fino a tutto il 2008 il capo del comitato per la standardizzazione del C++.
tomminno è offline   Rispondi citando il messaggio o parte di esso
Old 18-03-2010, 22:48   #18
WarDuck
Senior Member
 
L'Avatar di WarDuck
 
Iscritto dal: May 2001
Messaggi: 12815
Io ripeto secondo me che il problema è "a monte", ovvero verificare effettivamente cosa si possa definire "eccezione", e soprattutto se è il caso di fare un certo tipo di controlli per quelle parti di codice il cui comportamento è ben determinato.
WarDuck è offline   Rispondi citando il messaggio o parte di esso
Old 19-03-2010, 06:29   #19
cionci
Senior Member
 
L'Avatar di cionci
 
Iscritto dal: Apr 2000
Città: Vicino a Montecatini(Pistoia) Moto:Kawasaki Ninja ZX-9R Scudetti: 29
Messaggi: 53971
Quote:
Originariamente inviato da WarDuck Guarda i messaggi
Io ripeto secondo me che il problema è "a monte", ovvero verificare effettivamente cosa si possa definire "eccezione", e soprattutto se è il caso di fare un certo tipo di controlli per quelle parti di codice il cui comportamento è ben determinato.
Esatto
cionci è offline   Rispondi citando il messaggio o parte di esso
Old 19-03-2010, 08:39   #20
mcaisco
Member
 
Iscritto dal: Jun 2006
Messaggi: 117
In effetti le soluzioni sono molte per il semplice fatto ci sono infinte possibilità di complicare le cose. Quello che mi sembra strano è che non ci sia fondamentalmente una best practice per lo meno ufficiosa (se non ufficiale).

La gestione degli errori tramite eccezioni a mio parere e' utile solo in funzioni di libreria abbastanza generiche.
Secondo me infatti il modello delle eccezioni e' sostanzialmente uno "scarica barile" sul chiamante. E prima o poi qualcuno il barile deve per forza sobbarcarselo, cioe' qualche metodo-funzione deve prima o poi fare una catch e gestire l'errore. E quello a quel punto manda a farsi friggere il modello stesso della gestione degli errori tramite eccezioni.
Infatti quel metodo in caso di errore, invece di lanciare un'eccezione al chiamante a sua volta (come tutti gli altri metodi) deve gestire l'errore localmente nella calusola catch, sia che si tratti di errori generati da eccezioni lanciate da funzioni all'interno del corpo del metodo in questione, sia che si tratti di errori propri del metodo.

A quel punto al questione si sposta su "scegliere il metodo che gestisce l'errore". E' questo e' difficile, tanto difficile che alla fine ci si riduce a mettere il try-catch nel main. E alla fine nel main dell'errore non se ne sa una mazza ormai, perche' magari generato 10 livelli piu' sotto. L'unica cosa che si puo' fare e' mostrare un messaggio di errore con tutta lo stack trace!
mcaisco è offline   Rispondi citando il messaggio o parte di esso
 Rispondi


Intervista a Stop Killing Games: distruggere videogiochi è come bruciare la musica di Mozart Intervista a Stop Killing Games: distruggere vid...
Samsung Galaxy S25 Edge: il top di gamma ultrasottile e leggerissimo. La recensione Samsung Galaxy S25 Edge: il top di gamma ultraso...
HP Elitebook Ultra G1i 14 è il notebook compatto, potente e robusto HP Elitebook Ultra G1i 14 è il notebook c...
Microsoft Surface Pro 12 è il 2 in 1 più compatto e silenzioso Microsoft Surface Pro 12 è il 2 in 1 pi&u...
Recensione REDMAGIC Astra Gaming Tablet: che spettacolo di tablet! Recensione REDMAGIC Astra Gaming Tablet: che spe...
Tesla sta per lanciare il Robotaxi nella...
Dead Island 2 arriva su Mac, ma a un pre...
FIA e Formula E rinnovano il matrimonio:...
Windows 11 24H2 approda su nuovi sistemi...
Le restrizioni americane hanno generato ...
Una Mercedes EQS con batterie allo stato...
Il robot Walker S2 della Cina cambia la ...
Cosa vuol dire "vantaggio quantisti...
Retelit punta sulla connettività ...
Novità WhatsApp: promemoria sui m...
AMD: la prossima generazione di schede v...
MediaWorld potrebbe diventare cinese: Ce...
Amazon in delirio da sconti: 22 articoli...
EOLO ha più di 700 mila utenti in...
Una spin-off del MIT ha creato dei super...
Chromium
GPU-Z
OCCT
LibreOffice Portable
Opera One Portable
Opera One 106
CCleaner Portable
CCleaner Standard
Cpu-Z
Driver NVIDIA GeForce 546.65 WHQL
SmartFTP
Trillian
Google Chrome Portable
Google Chrome 120
VirtualBox
Tutti gli articoli Tutte le news Tutti i download

Strumenti

Regole
Non Puoi aprire nuove discussioni
Non Puoi rispondere ai messaggi
Non Puoi allegare file
Non Puoi modificare i tuoi messaggi

Il codice vB è On
Le Faccine sono On
Il codice [IMG] è On
Il codice HTML è Off
Vai al Forum


Tutti gli orari sono GMT +1. Ora sono le: 00:06.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Served by www3v