Exception vs "return boolean"

[guldo76]

Ciao,
mi chiedo se ci siano particolari considerazioni a favore di una strategia rispetto all'altra. Mi riferisco alle alternative:
1) nessun metodo restituisce void; piuttosto si restituisce un booleano e lo si controlla;
2) il metodo restituisce tranquillamente void, ma genera un'eccezione se fallisce.

Cosa ne pensate? Sono sempre indeciso se adottare una strategia o l'altra...

EDIT: mi riferisco in generale alla programmazione a oggetti

[71104]

devi rispettare il significato concettuale di valore di ritorno e di eccezione. evita di restituire un booleano solo per indicare una condizione di successo o di errore: il valore di ritorno é ció che la funzione deve calcolare, quindi se le fai restituire un booleano stai dicendo che quella funzione deve calcolare un booleano. io per indicare una condizione di errore uso sempre le eccezioni, sia in C++ sia in C# sia in Java (visto che non hai specificato il linguaggio).

tra l'altro in C++ lanciare un'eccezione spesso é piu efficiente: supponi di avere 5 chiamate annidate, 5 funzioni che si chiamano a catena e di cui l'ultima potrebbe fallire; inoltre supponi che la condizione d'errore debba essere semplicemente propagata e controllata solo "in cima", cio nella prima delle 5 funzioni.
se le 5 funzioni ritornano un booleano che indica la condizione d'errore allora devi usare 4 if, uno dopo ciascuna chiamata, mentre se usi il meccanismo delle eccezioni il flusso di esecuzione salta direttamente a monte in caso di eccezione.

naturalmente per far si' che la cosa sia realmente efficiente devi evitare la pessima abitudine di lanciare come eccezioni in C++ oggetti istanziati con new, altrimenti l'efficienza va a farsi benedire (per allocare nell'heap nel caso peggiore hai bisogno di uno switch in kernel mode, e comunque passi per tutta la trafila del CRT); piuttosto lancia un booleano:

void callee()
{
	if (error_condition)
	{
		throw false;
	}
}

void caller()
{
	try
	{
		callee();
	}
	catch (bool error)
	{
		// ...
	}
}

[Tommo]

Dipende da vari fattori decidere quale delle due usare... a mio parere delle linee guida sensate sono queste:

-interfaccia comune
Se già usi ovunque uno dei due approcci è meglio usare sempre lo stesso per non spiazzare l'user
-prestazioni
try catch dicono siano più lenti, quindi in sezioni time-critical potrebbe essere meglio bool
-probabilità di fallimento
Se l'eccezione è comune, e fornisce dei dettagli che servono a risolverla (es file mancante) indubbiamente è meglio un'eccezione.
-gravità dell'eccezione
Se dopo l'eccezione il programma è del tutto compromesso forse ha poco senso proprio lanciarla, tanto il programma andrà chiuso lo stesso.
-modo d'uso
A volte un bool può essere più elegante di una eccezione, se il caso false è perfettamente contemplato:

if( device->createWindow() )
...

E' molto più elegante del corrispondente try...catch, almeno secondo me.

Cmq tutto ciò è del tutto IMHO

[PGI-Bis]

Le eccezioni non sono un chè di particolare della programmazione orientata agli oggetti. Appartengono alla categoria delle condizioni nella teoria dei sistemi.

Anche un boolean può esprimere una condizione, da cui deriva l'incertezza.

Se il linguaggio non ha una sintassi ad hoc per le eccezioni chiaramente uno è costretto ad usare dei valori di controllo.

Se il linguaggio ha una sintassi ad hoc per le eccezioni allora uno DEVE usarle per la stessa ragione per cui al panettiere si chiede "uno sfilatino, grazie" e non "un cilindro, grazie". E' una questione di grammatica: se un fenomeno è identificabile con parole diverse si sceglie quella massimamente specifica.

Dunque ogni volta che incontri una condizione che determina impedimento al conseguimento di uno scopo per una causa esterna al processo che deve raggiungerlo spari un'eccezione.

In questo modo chi legge il codice sa che si è verificata una condizione che ha determinato impedimento... eccetera eccetera.

[guldo76]

Originariamente inviato da 71104

devi rispettare il significato concettuale di valore di ritorno e di eccezione. evita di restituire un booleano solo per indicare una condizione di successo o di errore

Grazie per la precisazione. Mi hai convinto.

Originariamente inviato da 71104

naturalmente per far si' che la cosa sia realmente efficiente devi evitare la pessima abitudine di lanciare come eccezioni in C++ oggetti istanziati con new, altrimenti l'efficienza va a farsi benedire [...] piuttosto lancia un booleano

Questo purtroppo in C# non si può fare, devo lanciare un'Exception (o un'istanza di una classe che eredita da Exception).

Cmq ora faccio così: catturo l'eccezione, scrivo un log e rilancio l'eccezione stessa.

Originariamente inviato da Tommo

Dipende da vari fattori decidere quale delle due usare... a mio parere delle linee guida sensate sono queste:

Grazie della risposta.

Chiaramente se in un progetto si è sempre fatto in un certo modo, è opportuno continuare per la stessa strada, sicuramente.

Originariamente inviato da Tommo

-modo d'uso
A volte un bool può essere più elegante di una eccezione, se il caso false è perfettamente contemplato

Oh, sicuro. Se la funzione ha lo scopo di dirmi se è verificata o meno una certa condizione, di sicuro deve restituire un booleano; ma se va in errore deve generare un'eccezione, e non restituire false come se avesse potuto controllare la condizione in questione senza problemi.

Grazie mille

[71104]

Originariamente inviato da Tommo

-interfaccia comune
Se già usi ovunque uno dei due approcci è meglio usare sempre lo stesso per non spiazzare l'user

l'utente mica deve leggere il codice

-prestazioni
try catch dicono siano più lenti, quindi in sezioni time-critical potrebbe essere meglio bool

"dicono" non é neanche lontanamente una "linea guida sensata"

-probabilità di fallimento
Se l'eccezione è comune, e fornisce dei dettagli che servono a risolverla (es file mancante) indubbiamente è meglio un'eccezione.

argomentazione inutile, se servono informazioni aggiuntive basta passare un puntatore a una struct (in C/C++) o restituire un intero oggetto (in C# o Java).

-gravità dell'eccezione
Se dopo l'eccezione il programma è del tutto compromesso forse ha poco senso proprio lanciarla, tanto il programma andrà chiuso lo stesso.

a maggior ragione in questo caso ha senso un'eccezione (non catturata) anziché una trafila di if: oltrettutto le eccezioni SEH in Windows permettono di collezionare un crash dump che l'utente puó inviare al programmatore il quale a sua volta puó caricarlo in un debugger e vedere esattamente cosa é successo.

-modo d'uso
A volte un bool può essere più elegante di una eccezione, se il caso false è perfettamente contemplato:

if( device->createWindow() )
...

e secondo te é perfettamente contemplato che il sistema non riesca a creare una cavolo di finestra?
qui era decisamente meglio un'eccezione.

[guldo76]

Originariamente inviato da PGI-Bis

Dunque ogni volta che incontri una condizione che determina impedimento al conseguimento di uno scopo per una causa esterna al processo che deve raggiungerlo spari un'eccezione.

OK, facciamo un esempio. Mi devo connettere a un DB che sta su una certa macchina remota. Evito di fare tutti i controlli che magari potrei: connettività alla rete, disponibilità della macchina, stato dell'istanza del DB, etc...
Provo semplicemente a connettermi: se riesco, OK, altrimenti genero un'eccezione (-> log) e fine del problema.
No?

[71104]

Originariamente inviato da guldo76

OK, facciamo un esempio. Mi devo connettere a un DB che sta su una certa macchina remota. Evito di fare tutti i controlli che magari potrei: connettività alla rete, disponibilità della macchina, stato dell'istanza del DB, etc...
Provo semplicemente a connettermi: se riesco, OK, altrimenti genero un'eccezione (-> log) e fine del problema.
No?

orientativamente si, ma se lavori in Java bada bene che sia un'eccezione checked e comunque (per C++ e C#) preoccupati di catturarla perché stiamo parlando di una condizione d'errore esterna che non puoi controllare.

[shinya]

Originariamente inviato da guldo76

Ciao,
mi chiedo se ci siano particolari considerazioni a favore di una strategia rispetto all'altra. Mi riferisco alle alternative:
1) nessun metodo restituisce void; piuttosto si restituisce un booleano e lo si controlla;
2) il metodo restituisce tranquillamente void, ma genera un'eccezione se fallisce.

Cosa ne pensate? Sono sempre indeciso se adottare una strategia o l'altra...

Una strada non esclude necessariamente l'altra.
Io in Java ogni tanto uso una classe che mi permette di scrivere qualcosa tipo:

// pseudo-java
final Either<ExpectedResult, AnException> result = myFunction();

if (result.isRight()) {
  // tutto ok qui ...
}
else {
  // oh noooeesss...
}
...

[PGI-Bis]

Originariamente inviato da 71104

orientativamente si, ma se lavori in Java bada bene che sia un'eccezione checked e comunque (per C++ e C#) preoccupati di catturarla perché stiamo parlando di una condizione d'errore esterna che non puoi controllare.

Bingo

Non parlerei tuttavia di condizione d'errore. L'errore è infatti un impedimento al raggiungimento dello scopo per causa interna. E' proprio il fatto che il verificarsi della condizione dipenda da un fattore esterno a determinarne la natura di eccezione.

[guldo76]

Originariamente inviato da 71104

orientativamente si, ma se lavori in Java bada bene che sia un'eccezione checked e comunque (per C++ e C#) preoccupati di catturarla perché stiamo parlando di una condizione d'errore esterna che non puoi controllare.

Sì sì, certo. Non mi sono espresso benissimo.
Diciamo che faccio qualcosa del genere (esempio semplificato):

static void Connetti(){
    try{
        ...
        ...
        ...
    }catch (Exception ex){
        ScriviLog(ex.Message);
        throw ex;
    }
}

static void Main(){
    try{
        Connetti();
    }catch {
        ScriviLog("bla bla");
    }
}

OK?

[shinya]

Originariamente inviato da guldo76

OK?

Mica tanto... quante volte scrivi nel log? Una volta per ogni rethrow?

[guldo76]

Originariamente inviato da shinya

Mica tanto... quante volte scrivi nel log? Una volta per ogni rethrow?

In linea di massima sì, per capire poi facilmente dal log in quale punto il programma è andato in errore. Cattiva idea? Come sarebbe meglio fare altrimenti?

[shinya]

Originariamente inviato da guldo76

In linea di massima sì, per capire poi facilmente dal log in quale punto il programma è andato in errore. Cattiva idea? Come sarebbe meglio fare altrimenti?

Facilmente? Con la stessa eccezione spalmata su tutto il log? Buona fortuna!

http://today.java.net/pub/a/today/20...ipatterns.html
Guarda qual'è il primo degli anti-pattern

[71104]

Originariamente inviato da guldo76

Cattiva idea?

*annuisce*

Come sarebbe meglio fare altrimenti?

esaminare lo stack trace: il log é qualcosa che viene letta dall'amministratore di sistema, il quale non ha i sorgenti e quindi puó fare poco con gli stack frame. non ti preoccupare di questi dettagli, lo stack trace completo ce l'hai nel crash dump

[guldo76]

Originariamente inviato da shinya

Facilmente? Con la stessa eccezione spalmata su tutto il log? Buona fortuna!

http://today.java.net/pub/a/today/20...ipatterns.html
Guarda qual'è il primo degli anti-pattern

Originariamente inviato da 71104

*annuisce*


esaminare lo stack trace: il log é qualcosa che viene letta dall'amministratore di sistema, il quale non ha i sorgenti e quindi puó fare poco con gli stack frame. non ti preoccupare di questi dettagli, lo stack trace completo ce l'hai nel crash dump

Crash dump?

Quindi mi state dicendo piuttosto è meglio non catturare mai nessuna eccezione se non nel Main, in cui prendo lo stack trace e lo scrivo nel log?

[71104]

Originariamente inviato da guldo76

Crash dump?

Quindi mi state dicendo piuttosto è meglio non catturare mai nessuna eccezione se non nel Main, in cui prendo lo stack trace e lo scrivo nel log?

lo stack trace non lo devi "prendere" tu: fa parte del crash dump, che viene collezionato automaticamente in un Windows opportunamente configurato quando un programma crasha per essersi lasciato scappare un'eccezione SEH; tutto questo discorso riguarda solamente il C e il C++ e solamente su Windows.

se invece vogliamo parlare di Java la risposta diretta a questo thread é: non ritornare mai valori che indichino condizioni di errore o di successo, usare sempre le eccezioni per indicare condizioni di errore e che siano eccezioni checked per errori causati da fattori esterni (mancaza di connettivitá, files di inizializzazione non trovati, ecc.) e unchecked per bug del tuo programma (riferimenti nulli, index out of bounds, ecc.); per quanto riguarda la cattura delle eccezioni: quelle unchecked lasciale sempre propagare, quelle checked catturale nel punto del programma in cui é appropriato reagire alla condizione d'errore. i crash dump in quella cagata di Java ( ) purtroppo non esistono, in caso di eccezione unchecked lo sviluppatore dovrá accontentarsi dello stack trace che viene stampato automaticamente da Java su System.out quando un'eccezione esce fuori dal main o dal metodo run di un thread.

per quanto riguarda infine C#, vale tutto come Java salvo che:
- non esiste distinzione tra eccezioni checked e unchecked, quindi questa distinzione é affidata a te che devi discernere tra quando catturare un'eccezione nel tuo codice e quando lasciarla andare.
- é possibile collezionare crash dump e caricarli nel debugger, ma purtroppo non ho idea di come si faccia.

[guldo76]

Grazie davvero per l'aiuto

Ma a questo punto mi chiedo:

Supponiamo che io abbia un metodo Main (che non restituisce nulla) che al suo interno chiama un metodo Login (che non restituisce nulla). Supponiamo che la procedura di Login fallisca per problemi di connettività, ma all'interno del metodo io mi occupi di gestire questa eccezione (checked) e scrivere sul log, senza rifare il throw dell'eccezione. A questo punto, il Main che ha richiamato il Login, come viene messo al corrente della situazione?

[cdimauro]

Originariamente inviato da 71104

i crash dump in quella cagata di Java ( ) purtroppo non esistono, in caso di eccezione unchecked lo sviluppatore dovrá accontentarsi dello stack trace che viene stampato automaticamente da Java su System.out quando un'eccezione esce fuori dal main o dal metodo run di un thread.

Hai detto niente.

per quanto riguarda infine C#, vale tutto come Java salvo che:
- non esiste distinzione tra eccezioni checked e unchecked, quindi questa distinzione é affidata a te che devi discernere tra quando catturare un'eccezione nel tuo codice e quando lasciarla andare.
- é possibile collezionare crash dump e caricarli nel debugger, ma purtroppo non ho idea di come si faccia.

Piccola nota: sembra che le eccezioni in .NET siano abbastanza lente, paragonate ad altri linguaggi/framework/runtime.

[71104]

Originariamente inviato da cdimauro

Hai detto niente.

mai visto un crash dump? mai provato a caricarlo in Visual Studio? é come fare il debug del programma al momento del crash: gli stack trace di ogni singolo thread sono il minimo.

Piccola nota: sembra che le eccezioni in .NET siano abbastanza lente, paragonate ad altri linguaggi/framework/runtime.

fonti?