Negare l'istanziazione!!

[kingv]

Originally posted by "dm69"



catch(...) prende qualunque eccezione senza distinzione, quindi e' Throwable.

non mi hai capito: sintatticamente e' quello (Throwable), ma non e' saggio fare il catch di qualcosa che non si puo' gestire, per cui e' meglio usare catch(Exception).

[dm69]

dm69 ha scritto:
Al codice chiamante non interessa sapere l'esatto statement che ha dato errore, al chiamante interessa sapere che qualcosa e' andato male, quindi basta che il codice chiamato generi un eccezione di tipo diverso per ogni errore che deve riportare (es. nel nostro caso: PasswordCheckException, BadUserNameException, ...) possibilmente tutte figlie della stessa classe di eccezione.

Infatti per "identificare l'istruzione" non intedevo l'istruzione all'interno della funzione che ha provocato il lancio dell'eccezione...ma quale istruzione all'interno di un blocco try ha generato l'eccezione... Mettiamo caso che ci siano 2 funzioni all'interno del blocco try che possono lanciare gli stessi tipi di eccezione...come faccio a sapere con la catch quale delle due ha generato l'eccezione ?

Se le due funzioni avessere tornato gli stessi numeretti nel caso di approccio C, come avresti fatto a capire chi delle 2 e' andata in errore?
Quello che poni non e' un problema delle eccezioni ma e' un problema di cattiva gestione dell'errore. Infatti se il chiamante deve capire esattamente cosa e' successo dobbiamo fare il throw di eccezini diverse oppure tornare numeretti diversi nel caso C.

dm69 ha scritto:
La gerarchia delle eccezioni la devi conoscere solo se devi fare azioni diverse a seconda dell'errore occorso. Lo stesso problema c'e' con la libreria del C: ogni funzione ritorna un numeretto che dice se tutto e' andato bene o no. Se poi vuoi proprio sapere che cosa e' successo ti devi studiare la documentazione e fare uno switch su errno.

Io non parlavo di identificare il tipo di errore, ma di identificare la funzione all'interno del blocco try che l'ha generato...
Metti che ci siano funzioni diverse all'interno del try e che ognuna possa lanciare un'eccezione diversa... Allora se volessi gestire gli errori di ogni funzione dovresti mettere una catch per ogni tipo di eccezione...
Mettiamo ora che queste eccezioni magari siano derivate l'una dall'altra...
A questo punto devi sapere la gerarchia delle eccezioni prima di poter disporre i blocchi catch nel modo giusto...non ti torna ?

Anche questo non e' un problema delle eccezioni, e' un problema di cattivo design: numeretti o eccezioni e' lo stesso!

[dm69]

Oggetto: Re: x cionci

--------------------------------------------------------------------------------

dm69 ha scritto:


Al codice chiamante non interessa sapere l'esatto statement che ha dato errore, al chiamante interessa sapere che qualcosa e' andato male, quindi basta che il codice chiamato generi un eccezione di tipo diverso per ogni errore che deve riportare (es. nel nostro caso: PasswordCheckException, BadUserNameException, ...) possibilmente tutte figlie della stessa classe di eccezione.




ti troveresti ad avere in un progetto decine (o centinaia) di eccezioni, con nessun vantaggio e un sacco di manutenzione in piu'.
in un driver jdbc secondo la tua teoria dovrebbero essere contenute qualcosa tipo 3-4mila classi di eccezione diverse (e se volessi sapere esattamente che errore ha generato una connect o uno statement dovresti scrivere un corrispondente numero di catch)

Se progettiamo con i piedi si!
Sistemi che usano le eccezioni per l'error handling tendono a definire parecchie eccezioni (il sistema che sto sviluppando al momento attuale consta di circa 200.000 righe di codice e ci sono una trentina di eccezioni).
Non e' detto che per ogni errore bisogna avere una eccezione diversa: per esempio un errore di lettura / scrittura / apertura / chiusura di un file si puo' reppresentare ad esempio con FileSystemException e dentro si puo mettere una stringa che da' un informazione dettagliata di cosa e' successo.

Secondo me avete una idea sbagliata della gestione delle eccezioni: le eccezioni non si devono catturare quasi mai, ha senso farlo solo se dobbiamo effettuare delle azioni di recovery, altrimenti le possiamo bellamente ignorare. Infatti provedono loro a terminare la funzione da cui e' saltata fuori l'eccezione e tutti i chiamanti finche' non arriviamo a un chiamante che deve prendere la contromisura all'errore che gli e' tornato.


Un codice che usa l'approccio C tende a essere cosi':

....

int ret_code = 0;

ret_code = f1();
if (ret_code == E_ERROR_CODE)
{
return E_ERROR_CODE;
}

ret_code = f2();
if (ret_code == E_ERROR_CODE)
{
return E_ERROR_CODE;
}

ret_code = f3();
if (ret_code == E_ERROR_CODE)
{
return E_ERROR_CODE;
}

....


un codice che usa le eccezioni tende a essere cosi:
.....
f1();
f2();
f3();
....


Non c'e' paragone no?

[cionci]

Originally posted by "dm69"


Secondo me avete una idea sbagliata della gestione delle eccezioni: le eccezioni non si devono catturare quasi mai, ha senso farlo solo se dobbiamo effettuare delle azioni di recovery

Infatti, ma mi sembra in contrapposizione con quello che dicevi tu

Originally posted by "dm69"


Un codice che usa l'approccio C tende a essere cosi':

Ma un codice del genere come diventerebbe con le eccezioni ?

if (f1() == E_ERROR_CODE)
Disconnetti();

if (f2() == E_ERROR_CODE)
PincoPallino();

if (f3() == E_ERROR_CODE)
TizioCaio();


Ma che stai scrivendo con 200.000 linee ?

[dm69]

Ma un codice del genere come diventerebbe con le eccezioni ?

if (f1() == E_ERROR_CODE)
Disconnetti();

if (f2() == E_ERROR_CODE)
PincoPallino();

if (f3() == E_ERROR_CODE)
TizioCaio();

In questo caso ovviamente bisognerebbe avere un try/catch per ogni chiamata.

Pero' il caso che proponi a me non capita quasi mai, perche' generalmente se qualcosa va' storto le operazioni di recovery le fanno i distruttori di oggetti creati lungo la sequenza di oparazioni.

Es:

RemoteConnection conn(hostname, port); // il costruttore si connette a un server remoto e lancia eccezione se qualcosa va' storto. Il distruttore si disconnette.

DB_Connection db_conn(db_name, username, passwd); // come sopra ma a un RDBMS

Results query_results; // oggetto che contiene i risultati della query. Il distruttore dealloca la memoria

db_conn.executeSomeQuery(query_results); // query_results viene riempito con i risultati della query. Lancia eccezione se qualcosa va male

conn.sendData(query_results); // per esempio i dati vengono mandati al server remoto. Lancia eccezione se qualcosa va storto.


Questo codice e' exception safe senza nessun try/catch e senza nessun ramo di codice di error handling! Fallo con un approccio classico e ti rendi conto di quanto codice noioso e error prone avresti dovuto scrivere.

Convinto?

[dm69]

Ma che stai scrivendo con 200.000 linee ?

E' un complesso sistema per fare ricerche geografiche su metadati di earth observation.

[cionci]

Sì ok...nel codice che hai proposto te lo userei anche io il sistema ad eccezioni...ma non si può generalizzare...

[dm69]

Certo non sempre le cose sono cosi eleganti, ma basta fare l'abotudine a questo modo di scrivere e poi vedrai che i casi che non possono ridursi a questo schema sono veramente pochi.

Ciao.

[dm69]

abitudine!!!