WebRequest fehler abfragen (sicher programmieren)

  • VB.NET

Es gibt 10 Antworten in diesem Thema. Der letzte Beitrag () ist von jvbsl.

    WebRequest fehler abfragen (sicher programmieren)

    Ich arbeite gerade an einem Programm mit update-check Funktion.
    Mein bisheriger Code:



    VB.NET-Quellcode

    1. webRequest = webRequest.Create("http://...*Pfad*.../current_version.txt")
    2. webresponse = webRequest.GetResponse() '=Fehlerquelle


    Gesammter Quelltext:
    Spoiler anzeigen

    VB.NET-Quellcode

    1. Sub update_check()
    2. Dim inStream As StreamReader
    3. Dim webRequest As WebRequest
    4. Dim webresponse As WebResponse
    5. Dim cversion As String
    6. webRequest = webRequest.Create("http://...*Pfad*.../current_version.txt")
    8. '# fehler abfrag die prüft ob die abfrage funktioniert
    9. If ???? Then
    10. status.Text = "Update-Check Error (Please check your internet connection and try again later) "
    11. webRequest.Abort()
    12. Me.UseWaitCursor = False
    13. Exit Sub
    14. End If
    16. webresponse = webRequest.GetResponse()
    18. inStream = New StreamReader(webresponse.GetResponseStream())
    19. cversion = inStream.ReadToEnd()
    20. ...
    21. ... rest der auswertung


    Leider lässt dieser das Programm abstürzen wenn keine Internetverbindung besteht

    Fehlermeldung:

    Quellcode

    1. Der Remotename konnte nicht aufgelöst werden: 'lewxx.de'

    Was ja auch verständlich ist, nur wäre es schön wenn man das gezielt abfragen könnte, anstatt das dann das Programm einfach abstürzt.

    deshalb meine Frage: wie kann man bei WebRequests fehler abfragen?[code]

    Erstmal mit My.Computer.Network.IsAvailable überprüfen, ob eine Netzwerkverbindung besteht, auf Verbindung zum Server könntest du evtl. mit der Ping Funktion vorher prüfen...
    Für unerwartete Fehler gibt es dann Allgemein noch den Try-Catch-Block ;)
    Ich wollte auch mal ne total überflüssige Signatur:
    ---Leer---

    In .NET gibt es die Fehlerabfrage mit Try...Catch, siehe hier

    Abfragen auf NetworkAvailable und Pingen hab ich ehrlich gestanden noch nie bei einem Code gesehen, schliesslich kann ja auch die WebSeite down sein (selbst wenn der Server generell noch antwortet).

    Hat geklappt
    vielen Dank ihr beide!

    hab nun beides drin:

    VB.NET-Quellcode

    1. Sub update_check()
    2. If Not My.Computer.Network.IsAvailable Then
    3. status.Text = "Update-check error: Please check your internet connection and try again later"
    4. Me.UseWaitCursor = False
    5. Exit Sub
    6. End If
    7. ' Testen ob version Aktuell ist
    8. Dim inStream As StreamReader
    9. Dim webRequest As WebRequest
    10. Dim webresponse As WebResponse
    11. Dim cversion As String
    12. webRequest = webRequest.Create("http://....../current_version.txt")
    14. Try
    15. webresponse = webRequest.GetResponse()
    16. Catch ex As Exception
    17. status.Text = "Update-check error: please try again later"
    18. Me.UseWaitCursor = False
    19. Exit Sub
    20. End Try
    22. inStream = New StreamReader(webresponse.GetResponseStream())
    23. cversion = inStream.ReadToEnd()

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von „LewxX“ ()

    Lass das mit dem isNetworkAvailable mal ruhig weg, ich glaube auch nicht dass jvbsl es damit sehr ernst gemeint hat ;)

    Noch ein paar Bemerkungen
    - fange nicht generell ex as Exception ab, sondern gezielt nur ex as WebException , um nur Netzwerk/Serverfehler abzufangen
    - man schliesst immer einen Streamreader mit .Close , war vermutlich in dem Code den Du nicht gepostet hast
    - man arbeitet mit dem httpWebRequest, die Klasse WebRequest ist eine abstrakte Klasse und dient nur als Basisklasse (~Baustein) für andere Klassen

    Lass das mit dem isNetworkAvailable mal ruhig weg, ich glaube auch nicht dass jvbsl es damit sehr ernst gemeint hat

    Hab ich schon, wenn dann kein Netzwerk vorhanden ist(und somit aufjedenfall auch kein Internet), dann ist der Abbruch wesentlich schneller als bei einem Ping ;)
    Ich wollte auch mal ne total überflüssige Signatur:
    ---Leer---

    jvbsl schrieb:

    Hab ich schon, wenn dann kein Netzwerk vorhanden ist(und somit aufjedenfall auch kein Internet), dann ist der Abbruch wesentlich schneller als bei einem Ping

    Das stimmt, deswegen lassen wir den unsinnigen Ping selbstverständlich auch weg, alle diese Fehler werden durch die WebException abgefangen ( und zwar im Millisekunden Bereich, TimeOut wird nicht abgewartet bei mangelnder Netzverbindung).

    jvbsl schrieb:

    im Normalfall versucht man Fehler erst gar nicht auftreten zu lassen, aber wenn es dir so besser gefällt

    Sorry, aber das ist ziemlicher Blödsinn , wenn Du Dir das mal genau überlegst: man versucht Fehler, die man vom Coding / Software Desgin beeinflussen kann, erst garnicht auftreten zu lassen.

    Dazu zählen normalerweise weder Power Failures, Hardware Defekte, Erdbeben und Cola in der Tastatur, noch nicht verbundene Netwerkkarten.

    Es gilt der Grundsatz Do report execution failures by throwing exceptions. If a member cannot successfully do what it is designed to do, that should be considered an execution failure and an exception should be thrown.
    Wenn also eine Prozedur einen Fehler nicht selber handlen kann, so berichtet sie dies der aufrufenden Routine durch eine spezifische und aussagefähige Exception.

    Das betrifft nun nicht Fehler, die zum normalen Control Flow gehören, also falsche Benutzereingaben ( Abfangen durch TryCast / TryParse) oder nicht gefundene Resourcen, zum Beispiel in einer Collection oder Assembly. In diesem Fall ist es sinnvoller spezifische Rückgabewerte (Nothing) zu verwenden. Es wird also unterschieden zwischen Ausahme- und (häufigen) Standardsituationen.

    Ich habe weder die Lust noch die Zeit jetzt eine ausführliche Diskussion vom Zaun zu brechen, aber genau wie für andere Coding Standards (Naming Standards ) gibt es für mich auch bei der Verwendung von Exceptions ein paar Grundsätze die man beachten sollte:
    - verwende Exceptions für Fehler die nicht ignoriert werden können /sollen
    - Fehler sollten bis zu der Ebene weitergereicht werden, die über den weiteren Kontrollfluss entscheiden kann
    - daher immer spezifische Catch Abfragen (nicht Catch ex as Exception oder gar leere Catch Blöcke )
    - Abfangen von Standardsituationen nicht durch Exception , sondern durch TryParse/TryCast
    - achja, und: vergiss nicht im Finally Blocl (unmanaged) Ressourcen auch wieder freizugeben

    Ausführlicher :
    - Exception Handling Best Practices in .NET auf Codeproject (lesenswert)
    - Microsoft's Design Guidelines for Exceptions

    Gruss

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „Kangaroo“ ()

    Soweit war mir das schon klar, aber sofern die Exception durch einen tatsächlichen Fehler auftritt und nicht durch ein vorheriges Abfragen, wie es hier der Fall ist(hab gerade nach geguckt), also muss ich dir wohl oder übel hier auch wieder recht geben...xD
    Ich wollte auch mal ne total überflüssige Signatur:
    ---Leer---

Facebook
Telefonspende