none
Far visualizzare errori/warnings da parte di visual studio quando non si gestiscono eccezioni RRS feed

  • Domanda

  • Considero il c# migliore di java, almeno sotto windows, per molti aspetti, ma una cosa che java fa, e che è necessaria a mio avviso, è quella di "costringere" il programmatore a gestire le eccezioni.

    Non possiamo conoscere tutte le eccezioni lanciate dalle funzioni che usiamo (tra l'altro ne usiamo parecchie anche di librerie di terze parti) nè possiamo dare per scontato che non si verificheranno mai...quindi io vorrei che quanto meno visual studio mi segnasse con warnings i punti in cui potrebbero nascere eccezioni...così da sapere dove mettere i try/catch e per cosa.

    E' possibile?



    • Modificato Squall867 venerdì 25 maggio 2012 19:54
    venerdì 25 maggio 2012 19:53

Risposte

Tutte le risposte

  • io vorrei che quanto meno visual studio mi segnasse con warnings i punti in cui potrebbero nascere eccezioni...così da sapere dove mettere i try/catch e per cosa.

    E' possibile?

    No, non è possibile. .NET non supporta le checked exceptions, condizione necessaria per avere una funzionalità di questo tipo.

    Se vuoi approfondire l'argomento, puoi dare un'occhiata a questo post: http://social.msdn.microsoft.com/Forums/it-IT/visualcsharpit/thread/3762067e-79d6-4d34-b29d-c9a60fefd1d1 in cui abbiamo parlato proprio di tale argomento.


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

    venerdì 25 maggio 2012 20:45
    Moderatore
  • Non è possibile e non avrebbe senso piazzare try/catch ovunque nel codice, che tra le altre cose diventerebbe inleggibile e molto poco performante.

    Se vuoi gestirle in modo centralizzato e catturare quelle inattese in Windows Forms puoi sottoscrivere gli eventi della classe Application, vedi qui http://similarimagesfinder.codeplex.com/SourceControl/changeset/view/42700#549376.

    Se ti interessa ho implementato un sistema a messaggi (che devo pubblicare) per inviare ai subscriber (ad esempio la form principale) le eccezioni non gestite, in modo da farle visualizzare all'utente o tentare di risolvere il problema.


    Matteo Migliore

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

    venerdì 25 maggio 2012 21:14
  • Ciao Squall867,

    You wrote on 25/05/2012 :

    E' possibile?

    no, ed è una scelta progettuale (di chi ha progettato il CLR) molto complessa.
    Le checked exception(s) diventano parte del contratto e sono quindi motivo di breaking changes, credo che chi ha fatto le scelte sul framework abbia ritenuto che i vamntaggi di averle non fossero superiori ai problemi di versioning che introducono.

    Ci sono toolkit come Codee Contracts o PostSharp che probabilmente ti permetterebbero di introdurre dei concetti simili.

    .m



    blog @ //milestone.topics.it
    sabato 26 maggio 2012 08:34
  • Bah per me è un errore enorme: mi sono trovato più volte a cliccare su un programma che aveva sempre funzionato e aveva smesso di farlo, ho dovuto riaprirlo con visual studio per capire che c'era un'eccezione di connessione dovuta al fatto che avevo dimenticato il bluetooth disattivato...dico, almeno un warning che mi dice : "senti questo metodo può lanciare un'eccezione" ...

    Sentite ma se per dire ho un codice tipo:

    ...
    connect()
    ...

    e nella mia applicazione utilizzo, come suggerito da matteo:

    AppDomain currentDomain = AppDomain.CurrentDomain;
          currentDomain.UnhandledException += new UnhandledExceptionEventHandler(MyHandler);

    e in MyHandler metto un bel dialog con la descrizione dell'errore ottengo almeno che l'applicazione partirà sempre, al max con un messaggio contenente l'errore?

    Quello che proprio voglio evitare è che al doppio click non compaia nulla...

    sabato 26 maggio 2012 12:06
  • Bah per me è un errore enorme: mi sono trovato più volte a cliccare su un programma che aveva sempre funzionato e aveva smesso di farlo, ho dovuto riaprirlo con visual studio per capire che c'era un'eccezione di connessione dovuta al fatto che avevo dimenticato il bluetooth disattivato...dico, almeno un warning che mi dice : "senti questo metodo può lanciare un'eccezione" ...

    Capisco che per te sia un errore enome, ma il linguaggio .NET è stato progettato senza checked exceptions (per i motivi che ti abbiamo spiegato), quindi quello che chiedi è assolutamente impossibile. Quello che puoi fare è dare un'occhiata ai toolkit che ti ha segnalato Mauro, e verificare se ti sono d'aiuto.

    e nella mia applicazione utilizzo, come suggerito da matteo:

    AppDomain currentDomain = AppDomain.CurrentDomain;
          currentDomain.UnhandledException += new UnhandledExceptionEventHandler(MyHandler);

    e in MyHandler metto un bel dialog con la descrizione dell'errore ottengo almeno che l'applicazione partirà sempre, al max con un messaggio contenente l'errore?

    Quello che proprio voglio evitare è che al doppio click non compaia nulla...

    Certo, un gestore centralizzato delle eccezioni, per gestire tutti gli errori non previsti, dovrebbe essere presente in ogni applicazioni. Puoi trovare maggiori informazioni su MSDN: http://msdn.microsoft.com/en-us/library/system.appdomain.unhandledexception.aspx.


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

    sabato 26 maggio 2012 12:35
    Moderatore
  • Le dialog vanno usate il meno possibile perchè interrompono il flusso di lavoro dell'utente e non sono un buono strumento per comunicare le eccezioni.

    Un modo meno invasivo può essere un "pannello" e magari un'animazione che segnalano il problema e danno la possibilità all'utente di consultare l'eventuale coda delle eccezioni potendala svuotare naturalmente.

    Matteo Migliore

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

    sabato 26 maggio 2012 12:55
  • Ciao Squall867,

    You wrote on 26/05/2012 :

    Bah per me è un errore enorme

    Qui c'è la spiegazione di tutto il misunderstanding tra i due mondi:
    http://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html

    ed è riassumibile in questa frase, secondo me:

    "If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception"

    e direi che è una mera questione questione filosifca, l'articolo linkato sopra presuppone che in Java, almeno io questo interpreto, lo stile di programmazione conceda l'uso delle eccezioni per gestire il flusso del programma.

    In .net, per motivi strettamente tecnici (non ho idea di come funzioni le eccezioni in Java), è sconsigliatissimo l'uso delle eccezioni per gestire il flusso, ergo ecco che in .net le eccezioni sono da considerarsi al pari delle RuntimeException di Java, e se c'è un'eccezione non gestita è perché si è verificato un problema da cui probabilmente non ha nessun senso fare recovery.

    my humble opinion,
    .m



    blog @ //milestone.topics.it
    sabato 26 maggio 2012 14:03
  • Ok grazie mille a tutti!
    sabato 26 maggio 2012 15:19