[VB2010 WinForms] ON ERROR GOTO/RESUME Vs. TRY/CATCH

[Vinsent]

Incuriosito dal thread di michelecali, dove ho scoperto ON ERROR GOTO/RESUME NEXT, ho fatto una (molto) veloce ricerca su internet dove ho superficialmente capito che:
1 è stato sostituito da TRY/CATCH
2 è stato mantenuto per motivi di compatibilità
3 è meglio usare TRY/CATCH
A scopo didattico, con il codice di test alla fine del post in cui genero un' eccezione sulla conversione da string a byte, ho cercato di fare le stesse cose usando i due metodi.
Penso che salti subito all' occhio che nella sub TRY_CATCH c' è molto più codice e vengono gestiste nel "particolare" solo le eccezioni della textbox1 mentre nella sub ON_ERROR le eccezioni possono essere gestite nel "particolare" per entrambe le textbox.
Quindi non mi spiego i tre punti sopra...mi stò perdendo qualcosa???
NB: portate pazienza, faccio tutt' altro mestiere che il programmatore, sono abbastanza autodidatta

 
    Dim a As Byte
    Dim b As Byte
    Dim f As String
    Private Sub TRY_CATCH() Handles Button1.Click
        a = 0
        b = 0
        f = ""
        Try
            a = CByte(TextBox1.Text)
        Catch ex As OverflowException
            If MessageBox.Show("errore overflow" & vbCrLf & "continuare?", "", MessageBoxButtons.YesNo, MessageBoxIcon.Question) = DialogResult.No Then
                Exit Sub
            Else
                f = f & "errore: " & ex.Message & vbCrLf
            End If
        Catch ex As InvalidCastException
            If MessageBox.Show("errore testo" & vbCrLf & "continuare?", "", MessageBoxButtons.YesNo, MessageBoxIcon.Question) = DialogResult.No Then
                Exit Sub
            Else
                f = f & "errore: " & ex.Message & vbCrLf
            End If
        Catch ex As Exception
            f = f & "errore: " & ex.Message & vbCrLf
        End Try
        Try
            b = CByte(TextBox2.Text)
        Catch ex As Exception
            f = f & "errore: " & ex.Message & vbCrLf
        End Try
        MsgBox("ERRORI" & vbCrLf & f)
    End Sub

    Private Sub ON_ERROR() Handles Button2.Click
        a = 0
        b = 0
        f = ""
        On Error GoTo Errori
        a = CByte(TextBox1.Text)
        b = CByte(TextBox2.Text)
        On Error GoTo 0
        MsgBox("ERRORI" & vbCrLf & f)
        Exit Sub
Errori:
        If Err.Number = 6 Then
            If MessageBox.Show("errore overflow" & vbCrLf & "continuare?", "", MessageBoxButtons.YesNo, MessageBoxIcon.Question) = DialogResult.No Then
                Exit Sub
            End If
        End If
        If Err.Number = 13 Then
            If MessageBox.Show("errore testo" & vbCrLf & "continuare?", "", MessageBoxButtons.YesNo, MessageBoxIcon.Question) = DialogResult.No Then
                Exit Sub
            End If
        End If
        f = f & "errore N° " & Err.Number & ": " & Err.Description & vbCrLf
        Resume Next
    End Sub

[michelecali]

1.che io sappia (per quel poco di esperienza avuta con il try catch) differisce solo dalla parte finally che viene forzatamente eseguita sempre , anche quando nella sezione di codice scritto in try o catch ci metto un exit sub o altri comandi di uscita , non esce dalla struttura se non dopo aver eseguito la parte di codice posta nel finally, mentre non è così per on error....
2. La struttura del try cacth è più ordinata, quella è , e quella rimane, mentre con l'altra non ci sono limiti ( vedasi se aggiungi il comando GOTO) le vie diventano infinite (quasi sempre ti perdi) ...
2.Un'altra differenza con try catch (che io sappia, magari qualcuno più esperto mi smentirà) non è possibile, in caso di errori, riprendere dall'istruzione successiva che ha generato l'errore stesso!!

.. altrA differenzA é una struttura legata al VB.NET, quindi l'abiente che si viene a creare è un sub ambiente , cioè le variabili dichiarate nel try cacth vivono solo in quella struttura...
Per ultimo, ON ERROR RESUME NEXT prova a metterlo dentro un ciclo, e fai sapere cosa succede... è nemico del VB.NET come l'istruzione già soppiantata in VB.NET "GOSUB".... (tra l'altro utilizzata molto in VB normale)

Spero sia stato d'aiuto...

[cyanuro]

Anche il goto dovrebbe essere del tutto abbandonato.
Un blocco di try / catch è fatto dal blocco principale di esecuzione
try
catch è eseguito invece in caso di errore
La codifica dell'errore specifico puè essere ulteriornmente gestita immettendo dei catch alternativi che portano ciascuno la "firma" del tipo che ha generato l'errrore.
Se non ne hai bisogno (cioè se non hai bisogno di gestire appositamente un errore) puoi anche limitarti ad un solo catch che intercetta Exception (generico)
all'interno del catch non credo sia molto regolare fare salti o gestire ulteriore codice che non sia strettamente necessario a mostrare l'errorre.
L'uscita dal blocco è invece automatica quindi non c'è bisogno di gestirla.
Invece esiste anche un blocco "finally" che è eseguito sia che si verifichino errori che il processo sia stato regolare.
Quindi riassumendo:
Try
Catch ex As Exception
MessageBox.Show (ex.Message) ' non quell'orrore di msgbox
Finally

[eternauta]

però che bei ricordi il GOTO.. mi riporta al basic che usavo sul fantastico (sono ironico) amstrad cpc 464..

forse sono ot ma vabe!!

Meglio che sia meglio il try cath visto che ci ho messo un pò a capirlo.

Ciao

[Vinsent]

Grazie per le risposte, bene o male ci ero arrivato da solo ma mi avete dato conferma.
Nel mio programma/laboratorio stò cercando di eliminare i vari try/catch intervenendo a monte dove possibile e dove ci riesco...l' istruzione on error per ora non dovrebbe servirmi.
Comunque, continuando il discorso su casi ipotetici, la differenza che mi ha più colpito è quella di poter continuare l' esecuzione del codice. Prendendo come esempio il codice nel post di Michele (Piacere, Vincenzo... ) dove nonostante ci siano delle eccezioni voglio arrivare alla fine e tenere traccia delle eccezioni, dovrei inserire ogni riga in un blocco try/catch e gestirne l' eccezione per cui mi sembra che on error possa essere ancora attuale ed utile.
Quindi se avessi la necessità dell' esempio sopra mi sembra più immediato usare on error una sola volta che una serie di try/catch. Mi stò perdendo nuovamente qualcosa?

@ Michele
ho provato ad inserire l' istruzione in un ciclo del mio programma ma sembra filare tutto liscio, qualche indizio per ricreare quello intendi?

@ cyanuro
cosa intendi con:

all'interno del catch non credo sia molto regolare fare salti o gestire ulteriore codice che non sia strettamente necessario a mostrare l'errorre.

Cioè, cosa può implicare eseguire codice o richiamare una sub all' interno del catch?

[michelecali]

[b]

Quindi se avessi la necessità dell' esempio sopra mi sembra più immediato usare on error una sola volta che una serie di try/catch. Mi stò perdendo nuovamente qualcosa?

ciao Roberto,
come nel mio post così come in questo tuo,questi casi dove ON ERROR GOTO .... è insostituibile.... A mio avviso microsoft non dovrebbe eliminarlo definitivamente, magari sostitituirlo con, magari una implementazione come:

ON ERROR (esegui Sub o metodo), secondo me sarebbe compatibile al 100% con l'ambiente .net e farebbe proprio al caso nostro

@ Michele
ho provato ad inserire l' istruzione in un ciclo del mio programma ma sembra filare tutto liscio, qualche indizio per ricreare quello intendi?

adesso non so il codice provato, il problema si presenta quando scatta l'errore, poi ti posto un'esempio...... Anche se si verifica un errore dentro la riga di una condizione IF THEN... , il blocco THEN viene sempre processato (almeno in VBA è così)

[michelecali]

Originariamente inviato da eternauta
però che bei ricordi il GOTO.. mi riporta al basic che usavo sul fantastico (sono ironico) amstrad cpc 464..

forse sono ot ma vabe!!

Meglio che sia meglio il try cath visto che ci ho messo un pò a capirlo.

Ciao

OT: io ricordo il basic su commodore 128 ogni riga di codice era numerata in ordine crescente, e quando inserivo una riga nuova, mi sballava tutto il codice con il GOTO numero riga....perchè il numero righe a seguire s'incrementavano di 1 certo che le cose son cambiate, di basic è rimasto poco... Adesso mi sembra un assemblato di tanti linguaggi in uno! Molto meglio adesso non c'è paragone!!

[ShaleN]

Il Try...Catch è (a mio modesto parere), migliore dell'ON ERROR perchè:

- Mettiamo che all'interno del Try hai del codice che può generare un'eccezione e che se la genera manda a monte tutto il resto del Try... non hai problemi, perchè il Try si ferma (mi spiego con un esempio, che è meglio:

Dim TextBox1 As New TextBox
Dim MiaStringa As String = "PincoPallo"

Try
   Dim Prezzo As Integer = CInt(MiaStringa)
   TextBox1.Text = CStr(Prezzo + 5)
Catch ex As InvalidCastException
   MessageBox.Show(ex.Message)
End Try

In questo caso, se la conversione va a monte, non ho problemi (come mi sembra ce ne siano con ON ERROR, che però non ho mai usato);

- Le eccezioni risalgono lo Stack finchè non trovano un blocco Try...Catch adatto a gestirle. Esempio:

Private Sub VerificaTry()
        Try
            GeneraEccezione()
        Catch ex As IO.InvalidDataException
            MessageBox.Show("InvalidArgumentException")
        End Try
    End Sub

    Private Sub GeneraEccezione()
        Try
            Throw New IO.IOException
        Catch ex As IO.IOException
            MessageBox.Show("IoException")
        End Try

        Try
            Throw New IO.InvalidDataException
        Catch ex As OverFlowException
            MessageBox.Show("OverFlowException")
        End Try
    End Sub

[michelecali]

sono daccordo che il TRY CACTH sia meglio di ON ERROR, non ho dubbi a riguardo... Ma ci sono casi in cui il codice successivo (successivo a quello che ha scaturito l'errore) debba essere eseguito.... E il TRY CATCH non da questa possibilità... A meno che non si voglia scrivere un blocco TRY CATCH per ogni singola istruzione....
per questo (per come la vedo io) servirebbe un'alternativa, nel caso del mio post, è insostituibile... il TRY CATCH non fa al caso...Classe per report errori generati, ON ERROR GOTO ... RESUME

[ShaleN]

In effetti, a volte può servire