Properties ... Fragen über Fragen ...

  • VB.NET
  • .NET (FX) 4.5–4.8

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

    Peter329 schrieb:

    Denn im Fehlerfall will ich ja eventuell bestimmte Programmteile ausführen bzw. nicht ausführen.

    Genau das ist der Sinn von Try-Catch & Exceptions ;)

    Und wenn eine Exception nicht behandelt wird, stürtzt das Program ab und es kommt nicht zu undefiniertem Verhalten.

    Ok, vom Coding her ist das wohl ziemlich Wurscht, ob man mit Try-Catch arbeitet, oder einen Return Code zurückliefert.

    Für meinen Geschmack bevorzuge ich den Return Code. Um alle Puristen zu beruhigen, ich verwende dafür jetzt eine eigene Enumeration:

    VB.NET-Quellcode

    1. Public Enum rc As Integer
    2. OK
    3. NotFound
    4. Duplicate
    5. Cancel
    6. Abort
    7. End Enum


    Und ich verwende eine eigene Property "ErrorMessage", um eine Fehlermeldung festzulegen. Denn die Fehlermeldung sollte m.E.genau dort festgelegt werden, wo der Fehler auftritt!

    Zu EDR habe ich allerdings eine alternative Ansicht. Programme sollten NICHT abstürzen. Ein Absturz hilft nämlich keinem Anwender! Ganz im Gegenteil:

    Da hat ein Anwender mühsam ein Panel mit zig Feldern ausgefüllt ... und dann bricht die Sch...sse ab, weil eine Datei gesperrt ist! Und er kann den ganzen Kram noch einmal eingeben ! Da kommt Freude auf. Diesen genialen "Design" haue ich jedem um die Ohren, der es wagt mir so was vorzulegen! Im richtigen Leben bin ich nämlich kein VB-Programmierer ! :)

    LG
    Peter

    Peter329 schrieb:

    Ein Absturz hilft nämlich keinem Anwender!
    Völlig korrekt, allerdings sollte während der Entwicklung jede auftretende Exception untersucht und bereinigt werden, jede mögliche ebenso.
    Für den Fall, dass Du mit "bedingten Haltepunkten" arbeiten willst, gugst Du hier.
    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!

    @Peter329 Da hast du EDR aber total falsch verstanden, primär geht es darum nicht wahllos alle Exceptions zu fangen und zu unterdrücken sondern eben solche Fälle explizit anzunehmen und eine Fehlerbehandlung zu implementieren. Im Falle deines Beispieles zb. ein Dialog der dem User mitteilt das die Datei in der gespeichert werden soll gesperrt ist und er zb. einen anderen Speicherort auswählen soll.

    Da hat ein Anwender mühsam ein Panel mit zig Feldern ausgefüllt ... und dann bricht die Sch...sse ab, weil eine Datei gesperrt ist! Und er kann den ganzen Kram noch einmal eingeben !Da hat ein Anwender mühsam ein Panel mit zig Feldern ausgefüllt ... und dann bricht die Sch...sse ab, weil eine Datei gesperrt ist! Und er kann den ganzen Kram noch einmal eingeben !
    ja, und was machste dann, wenn die Datei gesperrt ist? Einfach nicht abstürzen lassen geht nämlich garnet so ohne weiteres.

    Das ist eben der punkt. Die Leuts bauen einen TryCatch ein, bevor sie das Problem zuende durchdacht haben.

    Exceptions dienen dazu undefiniertes Verhalten zu verhindern. Enteder der Entwickler fängt diese auf und behandelt den Fehler oder das Program stürtzt ab. Ein Rückgabecode ist Schwachsinn, da brauchst du garnicht mit einer oo Sprache zu arbeiten. Es ist deutlich besser, wenn ein Programm sich beendet, als das es undefiniertes macht und weiß Gott was anrichtet. Noch besser ists allerdings wenn man Fehler behandelt.

    @ErfinderDesRades
    In dem Fall sollte man sogar ein Try-Catch drum bauen und anschließend im Catch Bericht an den User erstatten und ihn erneut auffordern eine Datei zu öffnen.

    ErfinderDesRades schrieb:

    noch besser ist, wenn man so proggt, dass keine Fehler auftreten.

    Wenn das möglich wäre, würde mans tun ^^ Ists leider oft nicht, allein das Beispiel des Öffnen einer Datei ist schon nicht immer fehlerfrei möglich.

    ich hab nicht gesagt, dasses immer möglich ist. Aber besser wärs doch, odr?
    Deshalb soll man sich darauf konzentrieren, und nicht einfach "TryCatch" hinschreiben, wo man keinen Absturz haben möchte.
    Weil das ist ein frommer Wunsch, der den Absturz nur wenig kümmert.
    Im Gegenteil: Der Absturz freut sich, wenn man Probleme nicht zuende durchdenkt.

    Und ein fehlerfreies Prog wirds nie geben, nicht mit und nicht ohne TryCatch.

    Da hast du Recht! Fehlerfreie Programme gibt es nicht und wird es nie geben.

    Aber es gibt Programme die klare Design Vorgaben verletzen. Wenn ein Anwender ein Panel ausfüllt und der Name des Speicherort veweist auf eine Datei, die gesperrt ist, dann darf die Anwendung NICHT abstürzen! Sondern es muss eine Fehlermeldung ausgegeben werden, die den Grund des Scheiterns anzeigt. Oft hat der Anwender die Datei selbst gesperrt ... oder er weiß, wo er anrufen muss, damit die Datei freigegeben wird. Und danach muss er den Befehl ohne Neueingabe wiederholen können.

    Solche Dinge sind für Anwender von enormer Bedeutung. Weil diese Leute nämlich mit so einem Sch..ss LEBEN müssen. Die kriegen ihre Arbeit nicht gebacken, wenn sie ständig ihre Eingaben wiederholen dürfen.

    Ich rede nicht über die Entwicklung. Ich rede über die finale Version. Und die darf nicht abstürzen. Weil dies das Vertrauen der Anwender untergräbt. Die Anwendung muss auch bei der blödesten Bedienung überleben. Das ist meine Doktrin.

    Bei Acceptance Test ist es übrigens meine beliebteste Übung, einfach wahllos irgendwelche Tasten zu drücken oder genau die Daten einzugeben die NICHT erwartet werden, um mal nachzuschauen, ob die Anwendung überlebt! :)

    LG
    Peter

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

    Peter329 schrieb:

    auf eine Datei, die gesperrt ist
    dann wird es beim ersten Zugriff, hoffentlich während der Entwicklung, knallen. Wenn Du die Ursache ermittelt hast, wirst Du Dir eine FileInfo-Instanz der Datei erstellen und alles mögliche abfragen, von Exists bis FileAttributs, da bekommst Du eine Info, ohne dass eine Exception geworfen werden muss, und jede bekannte Möglichkeit kannst Du per MessageBox melden und beseitigen lassen bzw. selbst beseitigen.
    Eine unbekannte Möglichkeit muss aber weiterhin als solche in Erscheinung treten, die könnte dann dem Entwickler als Exception / Assertion und dem Kunden als unerwarteter Fehler gemeldet werden.
    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!

    Gonger96 schrieb:

    Deswegen nutzt man in solchen Fällen Try-Catch ;)


    Aber davon hat EDR ja gerade abgeraten !

    @RFG Das meine ich ja ... ich denke, die erwarteten Konstellationen sollte man mit returnCode abhandeln ... und für die unerwarteten ist dann Try-Catch zuständig ... damit die Anwendung eben nicht abschmiert.

    Peter329 schrieb:

    und für die unerwarteten ist dann Try-Catch zuständig
    Jou.
    Im Catch-Zweig solltest Du aber z.B. den StackTrace abspeichern und Dir als Mail schicken bzw. den Nutzer bitten, dies zu tun.
    Denn unbekannte / unerwartete Exceptions unter den Tisch zu kehren ist nicht gut.
    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!

    Peter329 schrieb:

    Aber davon hat EDR ja gerade abgeraten !
    nö - hab ich nicht.
    Also höchste Priorität ist: das Prog macht niemals was anneres als was der User denkt, und Folgefehler müssen ausgeschlossen sein - insbesondere User-Daten dürfen nicht korrumpiert werden.
    Bedeutet (u.U.) konkret: Es darf nicht weiterlaufen, solange die Datei nicht zugreifbar ist. (Diesem ist Genüge getan, wenn man TryCatch weglässt.)
    Nun kannst du deinen ReTry coden, bei dem es solange in der Schwebe gehalten wird, bis der User telefoniert hat, oder es sonstwie geschafft hat, eine zugreifbare Datei zu besorgen. Oder whatever - ist mir ganz egal.
    Hautpsache du verstößt nicht gegen die Priorität: Das Prog darf nicht weiterlaufen, wenn die Datei nicht zugreifbar ist (anders gesagt: es wird "geschlossen" (um den Absturz nett zu benennen ;) ))

    Hast du einen solchen Retry, ja dann schreib TryCatch hin - dafür isser da. Aber code und teste erst den Retry - nicht vorher.

    Unerwartete Fehler werden immer abstürzen, sonst wären sie nicht unerwartet. Schreib Trycatch hin, und der Absturz (am Folge-Fehler) wird umso katastrophaler.

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

    (anders gesagt: es wird "geschlossen" (um den Absturz nett zu benennen ))


    Wie wäre es, wenn wir das Programm einfach mit einer Eingabeaufforderung ANHALTEN ... Und dieses Eingabepanel hat fünf Buttons:

    Help (um zu erläutern, was schief gegangen ist und was man dagegen tun kann)
    Retry ( um den Befehl noch einmal mit den gleichen Eingaben zu versuchen)
    Return (um das vorangehende Panel mit den unveränderten Eingaben anzuzeigen)
    Cancel (um die letzte Funktion zu beenden und die Eingaben zu verwerfen)
    Exit (um das Programm abzuschließen)

    Das ist es, was ich unter einer sauberen Benutzerführung verstehe.

    nix dagegen - hauptsache, es läuft nicht weiter und tut was anneres, als was der user denkt, und v.a. macht seine Daten nicht kaputt.

    hmm - wirklich gute idee :thumbsup: , weil sehr oft versteht der User bei den Fehlermeldungen nur Bahnhof (Fehlermeldungen sind eine Kunst für sich).
    Da bietest du ihm 1) Hilfe an,
    bzw. 2) vlt. hat er inzwischen das Prob behoben (Retry),
    bzw. 3) eiglich garnix (bei dir: Return),
    bzw. 4) er verzichtet auf die Operation,
    bzw. 4) Ende des Progs (was früher der Absturz war).

    hmm - hmm - ich sehe noch keinen funktionalen Unterschied zw. 2) und 3)

    Dieser Beitrag wurde bereits 6 mal editiert, zuletzt von „ErfinderDesRades“ ()