Alternative zu Try Catch gesucht - mir fällt keine ein

  • VB.NET

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

    Alternative zu Try Catch gesucht - mir fällt keine ein

    Guten Abend ihr lieben
    Ich habe eine kurze Sub geschrieben. Diese liest aus den Settings im DataSet eine URL (IP Adresse) und öffnet diese in einem WebView2.
    Wenn die Url nicht geöffnet werden kann, oder der User keine vergeben hat, soll ein MenuStrip Item versteckt werden.
    Die habe ich mit einem Try Catch Block gelöst - das funktioniert, aber eine Alternative wäre mir lieber - mir fällt nur keine ein.

    VB.NET-Quellcode

    1. ​ Private Sub LoadHomeAssistantURLOrHideMSItemIfNotPossible()
    2. Dim Settingsrow = BSEinstellungen.At(Of DtsDaten.EinstellungRow)
    3. Try
    4. UcHomeAssistant.WebView21.Source = New Uri(Settingsrow.HomeAssistantURL)
    5. Catch ex As Exception
    6. MSHomeAssistant.Visible = False
    7. End Try
    8. End Sub

    @DerSmurf Welche Exception wird denn geworfen?
    Laut MSDN ist der Try-Catch-Block in diesem Kontext völlig legitim.
    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!

    Du kannst mit Uri.TryCreate den String prüfen und das Boolean-Ergebnis hernehmen:

    VB.NET-Quellcode

    1. MSHomeAssistant.Visible = Uri.TryCreate(Settingsrow.HomeAssistantURL, UriKind.Absolute, Nothing) 'statt Nothing kannst Du (später) eine Variable vom Typ Uri verwenden, falls benötigt
    Abhängig vom String ggf. einen anderen UriKind-Wert nehmen.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    @VaporiZed Auch in Uri.TryCreate() wird intern nur eine Exception abgefangen (=> IlSpy).
    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!

    man könnte mal einen Haltepunkt setzen, und den genauen ExceptionTyp herausfinden. dann könnte man

    VB.NET-Quellcode

    1. Private Sub LoadHomeAssistantURLOrHideMSItemIfNotPossible()
    2. Dim Settingsrow = BSEinstellungen.At(Of DtsDaten.EinstellungRow)
    3. Try
    4. UcHomeAssistant.WebView21.Source = New Uri(Settingsrow.HomeAssistantURL)
    5. Catch ex As IvalidUriException
    6. MSHomeAssistant.Visible = False
    7. End Try
    8. End Sub
    coden oder sowas, und andere Exceptions werden nicht behandelt.

    Auch wenn ich manchmal ein bisschen brauche, bin ich doch lernfähig. (Keine Ironie) Dass ein Try Catch und einfach alle Exceptions unterdrücken übel ist, hab ich kapiert :o)
    Mir ging es aber darum, den Try Catch Block insgesamt los zu werden. Denn ich versuche darauf zu verzichten, wo es nur geht. Deswegen habe ich einfach global alles abgefangen (war zu faul :o)

    @VaporiZeds Lösungansatz scheint wunderbar zu funktionieren.
    Folgender Code macht genau, was er soll (wenn der User als HomeAssistant Url Nichts, oder Mist eingibt, wird der MenuStrip Eintrag nicht angezeigt. Mit gültiger IP wird der Eitnrag angezeigt und im WebView die Seite geladen):

    VB.NET-Quellcode

    1. Private Sub LoadHomeAssistantURLOrHideMSItemIfNotPossible()
    2. Dim Settingsrow = BSEinstellungen.At(Of DtsDaten.EinstellungRow)
    3. Dim HomeAssistantIP As Uri
    4. Dim ValidHomeAssistantIPSaved = Uri.TryCreate(Settingsrow.HomeAssistantURL, UriKind.Absolute, HomeAssistantIP)
    5. MSHomeAssistant.Visible = ValidHomeAssistantIPSaved
    6. If ValidHomeAssistantIPSaved Then UcHomeAssistant.WebView21.Source = HomeAssistantIP
    7. End Sub

    Ich habe gelernt, dass man eine Code so schreiben sollte, dass er erst gar nicht zu einer Exception führt. D.h. ich muss vorher alle aufkommenden Fehler abfangen und beseitigen. Der Try Catch Block ist dann für das zuständig, an dass ich noch nicht gedacht haben.
    NB. Es ist doch schön, wenn man lesbare Namen vergibt. Siehe auch [VB.NET] Beispiele für guten und schlechten Code (Stil).

    Du schlägst also vor, statt dem Framework-Einzeiler TryCreate einen kompletten URI-Parser selbst zu schreiben?
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    INOPIAE schrieb:

    Ich habe gelernt, dass man eine Code so schreiben sollte, dass er erst gar nicht zu einer Exception führt.
    Das ist erst dann erfolgreich, wenn Du sämtliche (bekannten und unbekannten) Testfälle durch exerziert hast.
    Ein Teil meiner Arbeit besteht darin, Testfälle zu generieren, um z.B. Bildverarbeitungsprozeduren zu testen. Und ich weiß, dass ich niemals eine vollständige Testliste haben werde.
    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!

    VB1963 schrieb:

    gemeint hat...
    Genau dort sollte kei Try-Catch stehen ...
    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!

Facebook
Telefonspende