Gestione corretta degli errori... chiarimento

[valeria75]

Dato che ho un po' di confusione e non ho ben capito come gestire errori
generati a catena (attraverso cath e throw) vorrei chiedervi un parere.
Ho una serie di metodi che vengono chiamati uno dopo l'altro e vorrei fare
in modo che l'errore generato nel metodo piu "lontano" (o nei metodi
intermedi) sia visualizzato anche nel metodo padre, o cmq che si
intercettato in qualche modo

Per maggiore chiarezze posto uno pseudo codice del mio applicativo:

nel form principale cerco di salvare un elemento nel DB

if (elemento.Save())
{
....
}
else
{
.....;
}


richiamo un metodo che verifica i campi


public Boolean Save()
{
if (ExQuery(strQuery))
{
...
}
....



che a sua volta richiama il metodo per il salvataggio nel DB



public Boolean ExQuery(string cmdText)
{
try
{
....
return true;
}
catch(Exception ex)
{
.....
return false;
}
}


In che punto mi consigliate di salvare l'errore in un log file e
visualizzare il messaggio di errore all'utente??
Come recupero errori scatenati nei metodi figli?

Thanks

[riccardone]

+ o -

Originariamente inviato da valeria75
try
{
elemento.Save();
...
}
catch(Exception ex)
{
logMessage("Aiuto e' successo qualcosa", ex.message);
}


private Boolean isValid()
{
if .... return false;
return true;
}

public Boolean Save()
{
if (this.isValid()) {
string cmdText = "UPDATE .....";
tuocommand.executenonquery();
return true;
} else {
throw new argumentexception("L'oggetto non e' valido");
}
}

[valeria75]

Grazie mille per la risposta dettagliatissima! Il fatto che tu abbia corretto direttamente il mio codice mi ha consentito di capire la logica corretta nella gestione degli errori.

Vediamo se ho capito:

nella prima parte di codice (quella che richiama i vari metodi a catena) metto la visualizzazione finale dell'errore... quindi verifica se è successo qualche cosa "prima" (ovvero nei metodi richiamati)


Save ritorna un boolean, quindi non saprò mai il tipo di errore generato, quindi salverei nel log l'errore proprio in questo punto .... dato che al livello superiore non potrei più riconoscere l'errore... qualche cosa del tipo:

// metto in try catch
if (this.isValid()) {
string cmdText = "UPDATE .....";
tuocommand.executenonquery();
return true;
} else {
throw new argumentexception("L'oggetto non e' valido");
// scrivo nel log l'errore generato dall'operazione

Altro dubbio:

il throw cosa fa esattamente???

throw new argumentexception("L'oggetto non e' valido");

mi restituisce qualche cosa?? oppure semplicemente il testo "L'oggetto non è valido"?? lo chiedo perchè, se non ho capito male, in questo codice:

catch(Exception ex)
{
logMessage("Aiuto e' successo qualcosa", ex.message);
}

ex non conterrà l'errore effettivamente generato (intendo l'errore visualizzato dal FMK)... cosa che invece vorrei "intercettare" nel metodo principale

Grazie ancora!

[riccardone]

Originariamente inviato da valeria75
Save ritorna un boolean, quindi non saprò mai il tipo di errore generato, quindi salverei nel log l'errore proprio in questo punto .... dato che al livello superiore non potrei più riconoscere l'errore... qualche cosa del tipo:

Non e' proprio cosi. La funzione save cosi come l'ho scritta ritorna un boolean ma in realta' potrebbe essere benissimo una piu' semplice void cioe' senza alcun valore di ritorno. Se nell'esecuzione del command (executenonquery) si sollevasse una qualsiasi eccezione (es. la colonna nel db non corrisponde) questa verrebbe automaticamente passata al chiamante e quindi memorizzata nel log. Quindi, non e' li che devi intercettare l'eccezione ma nel chiamante. Semmai, visto che li apri delle risorse, dovresti preoccuparti di chiederle prima di "passare la palla" al livello superiore. Quindi dovresti mettere il codice che interroga il db all'interno di un blocco try finally (senza catch) e nel finally mettere la chiusura della connection.

[riccardone]

Originariamente inviato da valeria75
il throw cosa fa esattamente???
mi restituisce qualche cosa?? oppure semplicemente il testo "L'oggetto non è valido"?? lo chiedo perchè, se non ho capito male, in questo codice:

Con il comando throw sollevi una eccezione. Non e' solo ado.net o il framework che sollevano eccezioni ma anche il codice che scrivi tu quando ad esempio l'utente non mette dentro i dati come vorresti (ed e' proprio il nostro caso). Se ad esempio l'utente mette un nome il cui numero di caratteri o composizione non ci piace sia il framework che il db magari non se ne accorgono ma noi si (es. controlli questi dati nella funzione isValid). Quando ce ne accorgiamo possiamo sollevare una nostra eccezione con throw new .... L'eccezione sollevata potra' essere una generica eccezione (throw new argumentexception("testo che vuoi restituire")) oppure puoi crearti una o piu' eccezioni custom.

[valeria75]

Quindi nel metodo principale riesco a ricevere l'errore grazie al throw?? indipendentemente da cosa ritorna il metodo chiamato?? ... allora posso salvare nel log direttamente da metodo principale.

Ma allora a cosa serve questo messaggio ("L'oggetto non e' valido")???

Se il throw ritorna al metodo chiamante l'errore effettivamente generato, dove viene visualizzato "L'oggetto non è valido"

Grazie

[riccardone]

naturalmente ho risposto un minuto dopo al discorso sul throw e quindi tutto cio' generera' una eccezione del tipo throw new argumentexception("scusa ma non avevo visto la seconda risposta")

[valeria75]

Adesso non ho capisco a quale domanda mi hai risposto

quindi cerco di chiarire quest'ultimo dubbio

Nel metodo principale, grazie al throw presente nel metodo chiamato, riesco a ricevere l'errore (effettivamente scatenato e non quello indicato tra apici "L'oggetto...") indipendentemente da cosa ritorna il metodo chiamato (bool, void...) ?? se la risposta fosse affermativa, potrei salvare nel log l'errore direttamente da metodo principale. (dato che riesco a recuperarlo)

Ma allora a cosa serve questo messaggio ("L'oggetto non e' valido")???

Se il throw ritorna al metodo chiamante l'errore effettivamente generato, dove viene visualizzato il messaggio "L'oggetto non è valido".

Grazie

[riccardone]

Visto che l'unico catch che hai nel codice e' nel client (o funzione principale come dici forse piu' chiaramente tu) qualsiasi eccezione venga sollevata nelle funzioni chiamate finira' li. Quindi e' li che potrai ritrovarti ad esempio con "L'oggetto non e' valido" nel caso a sollevare l'eccezione sia stata la funzione isValid, oppure "the column Nome dont exist in underlyng table" che potrebbe essere una ipotetica eccezione sollevata da un ipotetico database.

[valeria75]

ahhh, quindi

try
{
elemento.Save();
...
}
catch(Exception ex)
{
logMessage("Aiuto e' successo qualcosa", ex.message);
}


nel catch troverò

"L'oggetto non e' valido" se l'errore arriva da Save
AltroErrore se l'errore arriva da altri metodi richiamati nel try

ultima domanda: esiste un moto per intercettare l'errore effettivamente scatenato in Save e non il messaggio d'errore "L'oggetto non è valido"??

che vantaggi porta l'utilizzo del throw a questo punto??