Strict on - Die ersten Versuche.

  • VB.NET
  • .NET 4.5

SSL ist deaktiviert! Aktivieren Sie SSL für diese Sitzung, um eine sichere Verbindung herzustellen.

Es gibt 67 Antworten in diesem Thema. Der letzte Beitrag () ist von woeh.

    Strict on - Die ersten Versuche.

    also...ich habe mir ja das ehrgeizige ziel gesetzt mein programm auf strict on zu setzen und
    alles .net kompform zu schreiben.

    ich hätte es direkt machen sollen nach meinem umstieg, das sehe ich jetzt ein.
    aber was solls...frisch ans werk ;) immerhin will ich ja auch nur dazugehören ;)

    ich habe so an die fast 500 fehler wenn ich strict on stelle ;( ...also viel zu tun.

    ihr seht also...ich habe keine probleme damit fehler zuzugeben und öffentlich zu machen.

    meine erste frage:

    ich habe folgenden sub:

    VB.NET-Quellcode

    1. Public Sub CloseForm(ByRef frm As Form)
    2. On Error Resume Next
    3. frm.Close()
    4. frm.Dispose()
    5. frm = Nothing
    6. Err.Clear()
    7. End Sub


    bei strict on meckert er natürlich...setzte ich es auf ByVal bekomme ich logischer weise kein Form = Nothing zurück.
    ok....es sind nur 12 verweise....also könnte ich es auch per hand überall den code so schreiben.
    schöner fände ich allerdings einen sub oder eine funktion, die das erledigt.

    welche möglichkeit habe ich ?
    Hi
    zeige mal die Stelle, an der der Fehler auftritt.

    Verzichte außerdem unbedingt auf On Error Resume Next oder On Error GoTo. Diese verhindern einen sinnvollen Umgang mit Fehlern. Wichtig bei der Verwendung aller Methoden, die Fehler werfen können, ist, zu wissen, ob ein bestimmter Fehler ggf. auftreten kann und diesen entweder davor entsprechend zu behandeln (was in der Regel Priorität hat) oder über Try-Catch den Fehler abzufangen und jegliche Aktionen, die in diesem Aufruf stattgefunden haben und nicht erwünscht sind, umzukehren, bzw. auf Benutzereingaben zurückzugreifen, etc.

    Was ich vermute, ist, dass in deinem Code frm für die verschiedenen Forms aufgerufen wird, oder? Das könnte man über Generika lösen:

    VB.NET-Quellcode

    1. Public Sub CloseForm(Of TForm As Form)(ByRef frm As TForm)
    2. frm.Dispose()
    3. frm = Nothing
    4. Err.Clear()
    5. End Sub


    Viele Grüße
    ~blaze~
    hey, danke.....hat funktioniert :)

    ich werde ich noch einiges löchern, bis ich alle fehler weg bekommen habe:)

    on Error GoTo und GoTo generell habe ich gestern eleminiert...bis auf einen sprung....da muß ich mir was einfallen laßen...

    am anfang fand ich es sehr kompliziert....doch je mehr ich damit arbeite erkenne ich die vorzüge.

    danke für deine hilfe :)
    Und welche komplexe (Beispiel)konstruktion erfordert Deiner Meinung nach ein GoTo?
    ― Eine häufig von mir verwendete Abkürzung: CEs = control elements (Labels, Buttons, DGVs, ...)
    ― Meine wichtigste Programmiererkenntnis: Mühsam erhängt sich das Eichhörnchen.
    ― If Not GrammarIsOk() Then AssumeThatCodeIsOk = False
    ― »Oh, großes Spaghetticodemonster. Bitte schicke mir Durchblick! Oder zumindest eine Gabel. Oder – wenn es kein Besteck mehr gibt – zumindest Glasnudeln.«
    ehrlich gesagt war ich bis jetzt noch zu faul den letzten sprung umzuschreiben, weil es sich um einen sehr langen sub handelt.....es ist überschaubar....es war meine bis jetztige faulheit .)

    hey....ich bin bei 445 fehlern angekommen :)

    mist....läuft nicht mehr.....also nochmal von vorne....
    ich muß wohl alles korrigieren, testen, korrigieren, test u.s.w

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

    Wenn es sich wirklich

    woeh schrieb:

    um einen sehr langen sub handelt
    dann stellt sich die Frage, ob es nicht möglich ist, jenen Brocken in funktionale Stückchen zu häckseln und die dann in eigene Prozeduren zu packen, die dann einfach nacheinander aufgerufen werden. Früher galt zwar das Credo: Erst wenn etwas mehrfach verwendet wird, gehört's in eine eigene Prozedur. Ich denke aber (nein, das ist nicht auf meinem Mist gewachsen, ich hab auch jahrelang 500-Zeilen-Monster produziert), dass man alles, was einen Mini-Job erledigt (»tu alles« ist kein Mini-Job), gehört in eine Prozedur. So hab ich jetzt zwar viele Prozeduren (mit ziemlich eindeutigen Namen, sodass klar wird, was da genau passiert), aber länger als 10 Zeilen sind die selten. Erleichtert mir das Programmieren sehr.
    ― Eine häufig von mir verwendete Abkürzung: CEs = control elements (Labels, Buttons, DGVs, ...)
    ― Meine wichtigste Programmiererkenntnis: Mühsam erhängt sich das Eichhörnchen.
    ― If Not GrammarIsOk() Then AssumeThatCodeIsOk = False
    ― »Oh, großes Spaghetticodemonster. Bitte schicke mir Durchblick! Oder zumindest eine Gabel. Oder – wenn es kein Besteck mehr gibt – zumindest Glasnudeln.«
    So exzessiv betreibe ich es bspw. nicht. Normalerweise sind Probleme in verschiedene Subprobleme unterteilbar. Wenn es sich nicht um Kleinstprobleme handelt, die man innerhalb von gefühlten 30 Zeilen lösen kann (das ist einfach die Intuition) und sie eine Methode signifikant aufblähen, dann lagere ich sie aus, ansonsten eher nicht. Methoden, über 100 Zeilen schaue ich dan aber doch nochmal kritisch an und entscheide, ob sich nicht doch etwas sinnvoll auslagern lässt. Ist aber alles irgendwo eine Sache meiner Intuition (die nicht auf Faulheit basiert :D).

    Viele Grüße
    ~blaze~
    um nochmal auf CloseForm zurückzukommen...

    ich habe da ne weitere sub, die ich danach umgeschrieben habe

    VB.NET-Quellcode

    1. Public Sub QuitSub(Of TForm As Form)(ByRef frm As TForm)
    2. If frm IsNot Nothing Then
    3. CloseForm(frm)
    4. End If
    5. If cancelRead = True Then
    6. Log(LogColor.errorInfo, "Der Prozess wurde von dem Benutzer abgebrochen!")
    7. Message("Der Prozess wurde von dem Benutzer abgebrochen.")
    8. End If
    9. ShowMe(mainform)
    10. End Sub


    allerdings habe ich auch 7 verweise, die den sub mit nothing aufrufen, was natürlich nicht funktioniert...wie regel ich das ? nen neuen sub für die 7 verweise schreiben oder gibts ne möglichkeit ?

    ach ja...bin bei 387 fehlern angekommen *freu*
    Gibt es in Deinem Code tatsächlich solche Einzeiler? QuitSub(Nothing)? Dann würd ich mal sagen: rauslöschen. Fertig. Wie kommt sowas überhaupt dahin? Gab es da einen tieferen Sinn? Oder ist das die Folge der generischen Umgestaltung (deren Sinn ich noch nicht erfasst habe)?
    ― Eine häufig von mir verwendete Abkürzung: CEs = control elements (Labels, Buttons, DGVs, ...)
    ― Meine wichtigste Programmiererkenntnis: Mühsam erhängt sich das Eichhörnchen.
    ― If Not GrammarIsOk() Then AssumeThatCodeIsOk = False
    ― »Oh, großes Spaghetticodemonster. Bitte schicke mir Durchblick! Oder zumindest eine Gabel. Oder – wenn es kein Besteck mehr gibt – zumindest Glasnudeln.«
    der sinn ist, das bei jeder aktion der benutzer abbrechen kann. das wird in CancelRead gespeichert.
    bei jedem beenden der routine oder auch unterbrechung der routine wird geprüft ob der benutzer abgebrochen hat. das wird in dem sub QuitSub überprüft und ein möglicher fortschritt geschlossen.

    das ist der sinn dahinter.

    so leute....habe einiges geschafft & werde mal mein bett besuchen gehen :)

    danke euch allen für eure hilfe & geduld :)

    kann nur schlimmer werden .)

    gute nachtruhe an alle .)

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

    Und ByRef generell vermeiden.
    ByRef ist ein Spezial-Feature, was man nur in besonderen Fällen braucht - nämlich wenn man Functions hat, die eiglich mehrere Rückgabewerte haben sollten - was .Net ja (bislang) nicht kann.
    Braucht man keinen oder nur einen Rückgabewert gibts keinen Grund für ByRef, und sollte man tunlichst lassen, weil das kann zu bösen Überaschungen führen, insbes. in vb.net, wo beim Aufrufer am Code garnet erkenntlich ist, dass der übergebene Parameter hinterher ein anderer sein kann.

    woeh schrieb:

    VB.NET-Quellcode

    1. Public Sub QuitSub(Of TForm As Form)(ByRef frm As TForm)
    Was macht das / wozu brauchst Du hier das ByRef?
    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).
    VB-Fragen über PN / Konversation werden ignoriert!
    also...eine funktion läuft mit einer fortschrittsanzeige.
    der benutzer unterbricht oder eben nicht.
    QuitSub schließt und entlädt die fortschrittsanzeige und gibt, falls betätigt, eine meldung aus,
    falls abgebrochen wurde. die fortschrittsanzeige wird dann als nothing zurückgegeben.

    dummerweise funktioniert dies nicht, wenn ich die sub mit Nothing aufrufe...dann meckert strict on.
    Langsam. Nicht, dass wir hier aneinander vorbeireden: Option Strict On ist eine Einstellung, die die Designzeit/Programmschreibezeit betrifft. Sie macht sich nicht im Programmverlauf, also zur Laufzeit bemerkbar.

    woeh schrieb:

    dummerweise funktioniert dies nicht, wenn ich die sub mit Nothing aufrufe
    Dies ist nur ein Fall für Option Strict On, wenn irgendwo in Deinem Code Quit Sub(Nothing) steht. Und zwar genau so. Wenn es während der Programmausführung zu einem unvorhergesehenen Programmabbruch, ggf. mit Fehlermeldung kommt, hat das nichts mit Option Strict zu tun, da dies dann ein Laufzeitfehler ist. Daher: was ist der Fall? Fehlermeldungen, bevor das Programm gestartet wird oder Laufzeitfehler während des Programms? Zeig mal bitte nen entsprechenden Screenshot der Codezeite, in der das Problem auftritt.
    ― Eine häufig von mir verwendete Abkürzung: CEs = control elements (Labels, Buttons, DGVs, ...)
    ― Meine wichtigste Programmiererkenntnis: Mühsam erhängt sich das Eichhörnchen.
    ― If Not GrammarIsOk() Then AssumeThatCodeIsOk = False
    ― »Oh, großes Spaghetticodemonster. Bitte schicke mir Durchblick! Oder zumindest eine Gabel. Oder – wenn es kein Besteck mehr gibt – zumindest Glasnudeln.«