none
Gestione completa della catena eccezioni RRS feed

  • Domanda

  • Ciao a tutti.
    Volevo chiedervi se ci fosse un modo (tipo una funzione di test) per verificare che tutte le possibili eccezioni generabili dal codice siano gestite.
    In java ad esempio, il compilatore indica se non sono state gestite tutte le eccezioni che un preciso metodo può generare. In C# questo non avviene...
    Mi sapete dare una dritta? Grazie
    Haxl
    lunedì 27 febbraio 2012 12:22

Risposte

Tutte le risposte

  • C# non supporta le checked exceptions: non è possibile indicare quali sono le eccezioni lanciate da un metodo (non c'è il throws di Java, per intenderci).

    Se sei interessato alla cosa, qui: http://www.artima.com/intv/handcuffs.html trovi un'intervista in cui i designer del linguaggio spiegano perché hanno scelto questa strada. Altre informazioni a riguardo le puoi trovare in questo post: http://stackoverflow.com/questions/385913/why-wasnt-the-java-throws-clause-in-method-declaration-included-in-c.

    Di conseguenza, non c'è un modo per verificare se tutte le possibili eccezioni lanciate da un metodo sono gestite.


    Marco Minerva [MCPD]
    Blog: http://blogs.ugidotnet.org/marcom
    Twitter: @marcominerva

    lunedì 27 febbraio 2012 12:43
    Moderatore
  • in aggiunta puoi invece intercettare eccezioni non puntualmente gestite

    nell'appdomain: http://msdn.microsoft.com/it-it/library/system.appdomain.unhandledexception.aspx

    o per i web asp.net nell'Application_Error che trovi nel global.asax

    a presto


    Antonio Esposito [MCT, MCPD, MCTS, MCP]
    dotnetlombardia.org | blog | web | @tonyexpo
    Italy
     

    lunedì 27 febbraio 2012 15:03
    Postatore
  • Ciao e grazie ad entrambi per la risposta velocissima.

    @Marco: Ho letto adesso l'intervista a Hejlsberg e non mi trovo molto d'accordo avendo lavorato abbastanza con Java (non per mia scelta!). Vabbè, almeno magari in un futuro anche loro decideranno di inserire questo controllo di errori così potente ;)

    @Antonio: grazie per la conferma: allora avevo fatto bene già ad inserire il gestore delle eccezioni "non gestite" (!!!) nel Main del programma.

    A presto

    Haxl

    lunedì 27 febbraio 2012 15:18
  • @Marco: Ho letto adesso l'intervista a Hejlsberg e non mi trovo molto d'accordo avendo lavorato abbastanza con Java (non per mia scelta!). Vabbè, almeno magari in un futuro anche loro decideranno di inserire questo controllo di errori così potente ;)

    Dubito che verrà mai aggiunto :-)

    Se posso dirti la mia esperienza personale, io ho spesso sentito persone che si lamentavano per il fatto di essere obbligati a usare costrutti try... catch in Java anche quando erano sicuri al 100% che la chiamata al metodo non potesse lanciare l'eccezione prevista, perché avevano fatto controlli precedenti che impedivano il verificarsi di errori.


    Marco Minerva [MCPD]
    Blog: http://blogs.ugidotnet.org/marcom
    Twitter: @marcominerva

    lunedì 27 febbraio 2012 16:01
    Moderatore
  • Si può sembrare una rottura ma secondo me se un metodo può lanciare una eccezione nel 90% dei casi esiste una situazione, per quanto difficile da verificarsi possa essere, in cui lo farà!

    E se lo fa, avendo dato per scontato che non lo fa, il programma finale potrebbe avere un comportamento imprevedibile...per me non è professionale ragionare così!

    Inoltre fare controlli su dei valori è forse anche più una rottura di mettere un try catch a mio avviso (oltre a essere anacronistico: stiamo tornando al C!)...senza contare che molte volte usiamo anche librerie di terze parti e queste possono essere fatte sia da esperti che da non esperti, e questi ultimi magari non fanno nessun controllo e si affidano a quei 2-3 test in cui è andato tutto bene... [espressione non troppo elegante nei confronti di una persona è stata eliminata da moderatore]







    • Modificato Squall867 sabato 26 maggio 2012 12:20
    • Modificato Irina Turcu domenica 27 maggio 2012 18:49 Eliminata espressione non troppo elegante nei confronti di una persona.
    sabato 26 maggio 2012 12:17
  • Inoltre fare controlli su dei valori è forse anche più una rottura di mettere un try catch a mio avviso (oltre a essere anacronistico: stiamo tornando al C!)...

    Non sono assolutamente d'accordo. C'è un motivo ben preciso per cui è meglio fare controlli sui valori invece che usare le eccezioni. La gestione delle eccezioni ha un costo in termini di tempo di esecuzione, quindi dal punto di vista delle prestazioni è 1000 volte meglio effettuare un controllo a monte sui dati piuttosto che "andare dritti" ed utilizzare try... catch per trattare il caso di input non validi.

    Tanto per dirne una, questo è uno dei motivi per cui nella versione 2.0 di .NET sono stati aggiunti i metodi TryParse, per verificare se è possibile effettuare la conversione da un tipo all'altro, evitando di gestire l'eccezione nel caso di cast non valido.


    Marco Minerva [MCPD]
    Blog: http://blogs.ugidotnet.org/marcom
    Twitter: @marcominerva

    sabato 26 maggio 2012 12:47
    Moderatore
  • Marco ha perfettamente ragione.

    Seconda cosa, prima di dare giudizi di quel tipo su Hejlsberg o altre persone, è meglio essere sicuri di essere veramente esperti e competenti e anche in quel caso usare altri termini.

    Sei certo di potere progettare meglio il framework? Mi sembra un atteggiamento supponente.

    Matteo Migliore

    Bloghttp://blogs.ugidotnet.org/matteomigliore
    Twitterhttp://twitter.com/matteomigliore
    CodePlex

    sabato 26 maggio 2012 13:18
  • Non mi considero certo superiore, ma ho studiato l'ingegneria del software e qualcosa la so...le mie motivazioni, per quanto possano sembrare sbagliate, le ho scritte. Inoltre sarà anche vero che le eccezioni sono pesanti, ma è anche vero che rendono il codice più "sicuro" perché, appunto, obbligano chi lo scrive a considerare situazioni anomale e chi sfrutta metodi di terze parti a sapere cosa possono comportare.

    Considerando che i pc diventano di giorno in giorno più potenti, e considerando che il c# è fatto principalmente per applicazioni desktop, usare le eccezioni a scapito delle prestazioni per me è uno scambio più che accettabile.



    • Modificato Squall867 sabato 26 maggio 2012 15:28
    sabato 26 maggio 2012 15:25
  • Ho usato Java all'univesità, trovo .NET nettamente superiore sotto tutti i punti di vista e non sento minimamente la mancanza della gestione delle eccezioni di Java.

    Considerazioni personali a parte, nessuno obietta che tu possa essere in disaccordo, è sufficiente non offendere e rispettare.

    Matteo Migliore

    Bloghttp://blogs.ugidotnet.org/matteomigliore
    Twitterhttp://twitter.com/matteomigliore
    CodePlex

    sabato 26 maggio 2012 15:39
  • Sotto windows certamente il c# è il linguaggio migliore che ci sia, sono d'accorto con te!

    Cmq non credo di aver offeso nessuno, ho solo espresso la mia opinione condivisibile o meno...

    sabato 26 maggio 2012 17:27
  • Cmq non credo di aver offeso nessuno, ho solo espresso la mia opinione condivisibile o meno...


    Ciao Squall867,

    Come ti è già stato fatto notare, sul forum desideriamo ospitare un ambiente piacevole per tutti quanti, l’atteggiamento dei membri deve essere gentile, corretto ed appropriato, confacente ad un Forum pubblico di supporto tecnico. E’ sempre bene dare uno sguardo al regolamento quando non si è sicuri se una risposta può essere adeguata o no per l’ambiente in cui ci troviamo.

    Grazie per la tua collaborazione,


    Irina Turcu - Microsoft

    [Manifesto] Regole e Aspetti generali all'uso dei forum MSDN

    Questo contenuto è distribuito “as is” e non implica alcuna responsabilità da parte di Microsoft. L'azienda offre questo servizio gratuitamente, allo scopo di aiutare gli utenti e approfondire la loro conoscenza dei prodotti e tecnologie Microsoft.

    LinkedIn

    domenica 27 maggio 2012 18:50
  • Ciao Ragazzi,

    chiedo venia se mi intrufolo in questo interessante thread.

    L’argomento mi interessa molto, proprio perché sto approfondendo queste tematiche per meglio comprenderne le potenzialità e l’utilizzo.

    In breve … sto facendo dei test che simulano il lancio di un’eccezione  all’interno dell’evento “DataSet.DataTable.RowChanging”, quando l’evento viene scatenato sulla fase di commit (e.Action == DataRowAction.Commit && e.Row.RowState == DataRowState.Added).

    Questo, con l’intento fare propagare l’eccezione a livello di publisher e fare li quindi il catch.

    Il debugger però si stoppa con la segnalazione di eccezione non gestita sul subscriber.

    La cosa invece funziona tranquillamente, quando lo stesso evento viene eseguito sulla fase di “Fill” del DataGridView. Se simulo il thrown durante il upload delle righe, il metodo fill interrompe l’esecuzione e riesco a fare catch dell’eccezione a livello di evento Form_Load …

    Mi potete aiutare a capire il perché di questo differente funzionamento ?

    Grazie in anticipo.

    mercoledì 4 luglio 2012 13:56
  • Cosa intendi con publisher e subscriber? Chi sono gli attori in gioco?


    Marco Minerva [MCPD]
    Blog: http://blogs.ugidotnet.org/marcom
    Twitter: @marcominerva

    mercoledì 4 luglio 2012 17:35
    Moderatore
  • Scusami ... intendo il chiamante ed il chiamato ...

    Nello specifico la "form" e l'evento "RowChanging"  ... almeno, il contenitore principale è la form, ma posso considerare il chiamante la form, oppure il chiamante è la classe "DataTable" ?

    Perchè l'evento "RowChanging" viene triggerato dagli eventi della classe DataTable (intendo il metodo Fill ed Update).

    Comunque, il tutto fa riferimento ad una semplice applicazione windows, basata su di una form nella quale ho inserito un DataGridView, il quale a sua volta è appoggiato ad un DataSet.DataTable, collegato ad un semplice db access.

    Grazie.



    • Modificato Alevann giovedì 5 luglio 2012 16:25
    giovedì 5 luglio 2012 16:23
  • Il chiamante (sender) è l'oggetto che lancia l'evento, e quindi il DataTable.

    Non capisco quindi cosa intendi con "propagare l'eccezione a livello di publisher".


    Marco Minerva [MCPD]
    Blog: http://blogs.ugidotnet.org/marcom
    Twitter: @marcominerva

    giovedì 5 luglio 2012 17:27
    Moderatore
  • Considera che nel body dell’evento RowChanging, simulo una eccezione come la seguente

    private void myTable_RowChanging(object sender, DataRowChangeEventArgs e)

    {

    .

    ArgumentException ex = new ArgumentException("Error During Commit !!!");     

    throw (ex);

    .

     }

    Try/Catch a livello di chiamante, non mi intercetta l’eccezione:

    private void myTableBindingNavigatorSaveItem_Click(object sender, EventArgs e)

    {   

    this.Validate();      

    this.myTableBindingSource.EndEdit();     

    try     

    {        

    this.tableAdapterManager.UpdateAll(this.myDataSet);     

    }     

    catch (ArgumentException ex)     

    {        

    MessageBox.Show("ButAreYouWorking ???");      

    }


    }


    Come vedi la fase di commit e triggerata dall’evento click del BindingNavigator.

    Il flusso non arriva alla “catch” … IDLE (VS2010.Express), interrompe l’esecuzione sull’evento RowChanging, dicendomi che a quel livello l’eccezione “ArgumentException” non è gestita.

    Grazie.




    • Modificato Alevann venerdì 6 luglio 2012 14:35
    venerdì 6 luglio 2012 14:32
  • A seconda delle impostazioni di Visual Studio, è possibile che tutte le eccezioni vengano comunque segnalatate dal Debugger Assistant, ma probabilmente, se quando ti viene segnalata premi il tasto F5, dovresti arrivare al catch.

    Uso il condizionale perché non ho mai avuto modo di verificare il caso particolare nel caso degli eventi RowXXX del DataTable, ma vale la pena fare una prova :-)


    Marco Minerva [MCPD]
    Blog: http://blogs.ugidotnet.org/marcom
    Twitter: @marcominerva

    venerdì 6 luglio 2012 15:17
    Moderatore
  • Si, hai ragione.

    Sia premendo F5, che F11 arrivo al catch.  Quindi a tuo avviso è solo un problema di setup del Debugger Assistant ?

    Mi committa comunque la riga, quindi la throw non mi interrompe il metodo “Update” … qui, devo approfondire.

    Grazie mille.

    venerdì 6 luglio 2012 16:21
  • Sia premendo F5, che F11 arrivo al catch.  Quindi a tuo avviso è solo un problema di setup del Debugger Assistant ?


    Assolutamente sì... Ma non si tratta di un problema, ma di un'impostazione che trovi andando nel menu Debug e selezionando il comando Exceptions.

    Marco Minerva [MCPD]
    Blog: http://blogs.ugidotnet.org/marcom
    Twitter: @marcominerva

    venerdì 6 luglio 2012 16:34
    Moderatore