Sub indem Function/Sub eingebaut ist nicht benutzen

  • VB.NET

Es gibt 16 Antworten in diesem Thema. Der letzte Beitrag () ist von ErfinderDesRades.

    Sub indem Function/Sub eingebaut ist nicht benutzen

    Hallo an alle!

    Ich habe folgenden Code:

    VB.NET-Quellcode

    1. Private Sub NeuerSub
    2. Try
    3. 'nächster Sub ansteuern
    4. Catch ex As Exception
    5. 'evtl. Sub wiederholen
    6. 'nächsten Sub auslassen
    7. End Try
    8. End Sub

    Das soll in diesem Sub(ButtonClick) wieder auftauchen:

    VB.NET-Quellcode

    1. Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
    2. NeuerSub()
    3. '...
    4. '...
    5. '...
    6. End Sub

    Jetzt soll halt wenn es im "NeuerSub" einen Fehler(Exception) gibt der Button1 nicht weiter ausgeführt werden. Jedoch soll die Funktion wiederholen im "NeuerSub" erhalten bleiben.

    Ich hoffe man versteht mein Problem :)

    LG
    Alpha11833

    VB.NET-Quellcode

    1. Private Function NeuerSub() As Boolean
    2. Try
    3. 'nächster Sub ansteuern
    4. Catch ex As Exception
    5. 'evtl. Sub wiederholen
    6. 'nächsten Sub auslassen
    7. Return False
    8. End Try
    9. Return True
    10. End Function

    Wozu Try / Catch?
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Generell solltest du dir dafür mal Functions angucken.

    VB.NET-Quellcode

    1. Public Function <Name>([paramList]) As <ReturnValue> ' Hier bietet sich bei dir Boolean an
    2. Try
    3. ' Do Something
    4. Return True
    5. Catch ex As Exception
    6. ' Do Something
    7. Return False
    8. End Try
    9. End Function
    11. ' Dein Button
    12. '...
    13. If Not <Funktion> Then Return
    14. '...


    Ansonsten gucken, wie du Try Catch vermeiden kannst.... es ist selten der beste Weg. Zumal, wenn du ein geregelten anderes Verhalten hast, kannst du da auch mit Funktionen arbeiten und locker dein Try Catch raus schmeißen...

    lg.

    zb:

    VB.NET-Quellcode

    1. Private Sub Button1_Click(sender As System.Object, e As System.EventArgs) Handles Button1.Click
    3. Static CanDo As Boolean = True
    4. If Not CanDo Then Exit Sub
    5. Try
    6. ThrowError()
    7. Catch ex As Exception
    8. CanDo = False
    9. End Try
    11. End Sub
    13. Private Sub ThrowError()
    15. Dim i As Integer
    16. Try
    17. Debug.Print("Doing something stupid")
    18. i = 2 \ i
    19. Catch ex As Exception
    20. Debug.Print("Doing something stupid .. again")
    21. i = 2 \ i
    22. End Try
    24. End Sub


    Will man den Status zurücksetzen können, muss man das "CanDo" natürlich auf Klassenebene deklarieren.

    1) Try/Catch: natürlich versucht macht er noch was anderes (in diesem Fall die Internetverbindung Prüfen)
    2) Danke!! Also in Zukunft lieber Try/Catch vermeiden! Und natürlich hast du recht die Funktionen hab ich vor lauter Try/Catch nicht mehr berücksichtigt!
    3) Ebenfals danke! Ich werde jedoch erstmal versuchen Try/Catch aus zu lassen!

    Wenn jemand den besten Weg weiß um eine bestehende /nicht bestehenede Internetverbindung zu prüfen, kann er das gerne auch tun! (Jedoch habe ich in meinem Programm sehr viele Try/Catch-Befehle :( )


    LG

    Mach einen Ping an den Server.
    Suche nach Ping Server im Forum.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    RodFromGermany schrieb:

    Mach einen Ping an den Server.
    Achso hab ich vergessen:

    VB.NET-Quellcode

    1. My.Computer.Network.Pin("google.com") 'da google immer erreichbar sein wird :D

    Hab ich schon, aber trotzdem Danke!
    Es gibt doch da nur die Möglichkeit Try/Catch anzuwenden, ansonsten wird für den User nichts angezeigt und man kann es nicht prüfen!

    LG

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Alpha11833“ ()

    RodFromGermany schrieb:

    Mach einen Ping an den Server.

    Ja genau ...

    Was macht Ping ohne Internet? Schmeißt ne Exception ...

    Lieber TE: Exceptions sind ... GUT! Verwende sie immer da, wo du vom Betriebssystem oder einer Funktion eine "Antwort" erwartest, die eben NICHT als Funktionswert geliefert wird oder werden kann.
    Das Thema TryCatch hatten wir oft genug ... leider ist da viel Unfug mit dabei. Im Zweifel empfähle ich "CLR via C#" von Jeffrey Richter. DER ist nun garantiert nicht frei von "eigenen" Vorstellungen (Properties vermeiden etc), aber ein ausgewiesener Experte und absolut NICHT gegen Exceptions und Try-Catch. WENN man weiß was man tut ... aber wer nicht weiß, was er tut, sollte stricken und nocht programmieren!

    picoflop schrieb:

    Verwende sie immer da, wo du vom Betriebssystem oder einer Funktion eine "Antwort" erwartest, die eben NICHT als Funktionswert geliefert wird oder werden kann.
    jo, scheint mir auch eine sinnvolle Bedingung, wann TryCatch einzusetzen sinnvoll ist.

    Aber so wie hier malwieder eher nicht:

    VB.NET-Quellcode

    1. Catch ex As Exception
    weil das fängt alle Exceptions ab, dies gibt, und nicht nur die Exceptions, die die erwartete Antwort des Betriebssystems enthalten (etwa die PingException).
    Damit hat man also sich malwieder die Debugging-Möglichkeiten selbst weggecatcht für alle wirklichen Fehler, die vlt. auch noch auftreten mögen (es sei denn, genau das ist tatsächlich das erwünschte Verhalten).
    TryCatch ist ein heißes Eisen

    picoflop schrieb:

    Exceptions sind ... GUT!

    Da stimme ich zu (und ich will auch keine Diskussion wieder hier anfangen).

    Worauf ich hinaus wollte, in dem Fall des anpingens scheint es in Ordnung zu sein, dass in einen Try Catch zu packen, kenne die Ping-Funktion nicht (sprich ich habe sie bisher nicht gebraucht)
    Es gibt nur leider zu oft dass Problem, dass die Leute einfach alles catchen und verschlucken... wie hier mit geregelten Ausnahmeverhalten mag dass in gesunden Maße in Ordnung sein, aber es ist dennoch oft nicht nötig.

    BSP: Ich möchte Casten.

    VB.NET-Quellcode

    1. Try
    2. Dim i As Integer = DirektCast("Milch", Integer)
    3. Catch ex As InvalidCastException
    4. MsgBox("Wert kann nicht gecastet werden")
    5. i = -1
    6. End Try
    8. ' An einer solchen Stelle mMn besserer Weg:
    10. Dim i As Integer = TryCast("Milch", Integer)
    11. If i = Nothing Then
    12. MsgBox("Wert kann nicht gecastet werden")
    13. i = -1
    14. End If


    Nicht getestet, aber sollte so in beiden Fällen die Meldung bringen...

    Der Unterscheid: Eine überprüfung auf Nothing an dieser Stelle dauert einige wenige Millisekunden, das Try Catch einige 100. Nur als Beispiel zu sehen. Aber es gibt viele Fälle wo man so den Try Catch umgeht. Prüfen ob eine Datei da ist bevor sie geöffnet wird, Streamende ohne schmerzhaften Try Catch erkennen...

    Also TE: Du darfst Try Catch benutzen, nur ist es immer gut, alternativen zu suchen, um es zu vermeiden. Ich benutze sie auch. Ich habe in 5000 Zeilen Code aktuell 7 mal Try Catch, weil nichts anderes übrig bleibt... ;)

    picoflop schrieb:

    wo du vom Betriebssystem oder einer Funktion eine "Antwort" erwartest, die eben NICHT als Funktionswert geliefert wird oder werden kann.
    All das ist so ziemlich der größte Umfang am Programmieren :D
    Danke für deine Aufklärung!
    PS: Was bedeutet "TE"?

    ErfinderDesRades schrieb:

    Aber so wie hier malwieder eher nicht:
    ...
    weil das fängt alle Exceptions ab, dies gibt, und nicht nur die Exceptions, die die erwartete Antwort des Betriebssystems enthalten.
    TryCatch ist ein heißes Eisen
    Ja schon, allerdings geht man sicher, dass das Programm nicht abschmieren kann ;) Die Fehler beim Debuggin sieht man ja sowieso und kann diese Beheben.


    LG

    Naja, man sollte dennoch nicht einfach alles Catchen...

    Zumal, du willst nur gewisse Ausnahmen behandeln. Nicht alle. Vielleicht gibt es welche, die du nicht bedenkst, dann sollte der Fehler geworfen werden oder zumindest der Fehler irgendwo hin geloggt werden, weil ds kann zu einer vorerst unbemerkten Fehlfunktion führen.

    /Offtopic: TE = Thread-Ersteller, also du

    OK, hast auch mal wieder recht ^^

    Fakt ist aber, dass es nicht zum besten Stil gehört, einfach alles zu schlucken... da lass ich lieber das Programm abschmieren und der Kunde sagt es mir am Ende als dass es einfach... falsch läuft ^^

    Alpha11833 schrieb:

    Ja schon, allerdings geht man sicher, dass das Programm nicht abschmieren kann

    die katastrophal falsche übliche Vorstellung von TryCatch.
    Es kann nämlich u.U. wunderbar abschmieren - besser als zuvor! Zwar an genau dieser Stelle nun nicht mehr, aber dafür gleich um die nächste Ecke - und dann fiel Fergnügen bei der Fehlersuche ;)
    Lies dir TryCatch ist ein heißes Eisen mal wirklich durch.

Facebook
Telefonspende