Mögliche Programmabsturzfehler

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

Es gibt 15 Antworten in diesem Thema. Der letzte Beitrag () ist von Yanbel.

    @Haudruferzappeltnoch So was:
    Projekt => Eigenschaften => Anwendungsereignise anzeigen
    MyApplication => MyApplication.Ereignisse auswählen
    UnhandledException erstellen lassen
    =>

    VB.NET-Quellcode

    1. Imports Microsoft.VisualBasic.ApplicationServices
    3. Namespace My
    4. ' Für MyApplication sind folgende Ereignisse verfügbar:
    5. ' Startup: Wird beim Starten der Anwendung noch vor dem Erstellen des Startformulars ausgelöst.
    6. ' Shutdown: Wird nach dem Schließen aller Anwendungsformulare ausgelöst. Dieses Ereignis wird nicht ausgelöst, wenn die Anwendung mit einem Fehler beendet wird.
    7. ' UnhandledException: Wird bei einem Ausnahmefehler ausgelöst.
    8. ' StartupNextInstance: Wird beim Starten einer Einzelinstanzanwendung ausgelöst, wenn die Anwendung bereits aktiv ist.
    9. ' NetworkAvailabilityChanged: Wird beim Herstellen oder Trennen der Netzwerkverbindung ausgelöst.
    10. Partial Friend Class MyApplication
    11. Private Sub MyApplication_UnhandledException(sender As Object, e As UnhandledExceptionEventArgs) Handles Me.UnhandledException
    12. ' was tun:
    13. MessageBox.Show("UnhandledException", e.Exception.Message)
    14. End Sub
    15. End Class
    16. End Namespace
    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!

    Haudruferzappeltnoch schrieb:

    normalerweise wenn der Code auf ein Problem läuft bekommt man eine Fehlermeldung. Kann es sein, dass es auch Fehler gibt wo diese Meldung ausbleibt und das Programm einfach so beendet?

    In bestimmten Konstelationen kann das passieren, kommt meiner Erfahrung nach aber sehr selten vor.

    Haudruferzappeltnoch schrieb:

    Oder kann man so eine Fehlermeldung abschalten?

    Keine Ahnung, aber warum sollte man das tun?
    Um die Fehlersuche etwas sportlicher zu gestallten?!

    Naifu schrieb:

    Um die Fehlersuche etwas sportlicher zu gestallten?!
    Minimum wäre aufzuklären.
    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!

    Den Spaß hatten wir wohl alle schon, wenn Exceptions im Form_Load-EventHandler auftreten. Werd mal konkret. Bei welchem Code erwartest Du welchen Fehler?
    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.

    Willst Du das Progrämmchen hochladen? Vielleicht finden wir die Ursache. Ist es scheinbar zufällig oder wenn Du bestimmte Aktionen durchführst?
    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.

    In der Anfangszeit hatte ich diese unerklärlichen Abstürze auch häufig.
    Das Programm lief manchmal mehrere Stunden und hunderte Clicks der User einwandfrei und dann irgendwann wurde das Programm ohne Fehlermeldung abgebrochen.

    Schuld daran war bei mir damals Fenster Aufrufe mit .ShowDialog() ohne dann nachher das Fenster mit .Dispose wieder löschen zu lassen.

    Je nachdem nach 100-200 Aufrufen des Fensters war es dann soweit.

    Der flotte Johann schrieb:

    Schuld daran war bei mir damals Fenster Aufrufe mit .ShowDialog() ohne dann nachher das Fenster mit .Dispose wieder löschen zu lassen.
    Das geht so:

    VB.NET-Quellcode

    1. Using dlg = New MyDialog()
    2. dlg.ShowDialog()
    3. End Using
    Gugst Du auch hier: Dialoge: Instanziierung von Forms und Aufruf von Dialogen
    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!

    Ich klinke mich hier mal ein. Ich hab das bei meinem Programm leider auch ab und an - scheint öfter dann zu passieren, wenn die Verbindung zur Datenbankdatei auf dem Netzlaufwerk zu langsam ist.
    Dann schließt sich das Programm auch einfach ohne Fehlermeldung. Programm danach neu aufmachen, haargenau die gleiche Vorgehensweise und auf einmal klappt das wie es soll und Programm bleibt
    offen...

    Finde das auch nervig und bin dem noch nicht auf die Schliche gekommen, werde es aber mal mit Rod's unhandledexception-methode
    testen :)
    "Na, wie ist das Wetter bei dir?"
    "Caps Lock."
    "Hä?"
    "Shift ohne Ende!" :thumbsup:

    Naja, UnhandledExceptions sind aber m.E. die, die zwar auftreten, aber nicht vom Programmierer abgefangen werden (unhandled eben). Standardmäßig (Debug-Konfiguration) bekommt man ja eben eine Exception-Meldung, nämlich sowas:

    Also wenn eine Exception auftritt, man diese aber nicht mit Try-Catch verarbeitet. Statt diesem Fenster kann man dannn eben den UnhandledException-EventHandler nutzen, um dann was anderes anzeigen zu lassen, aufzuräumen, ne Mail zu schicken, sonstewas. Aber wenn das Programm "einfach so" abstürzt, wird das vermutlich nix bringen. Ok, "einfach so" wird ein Programm nie abstürzen, aber ob der genannte EventHandler immer greift?
    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.

    Ich kann mir sehr wohl vorstellen, dass das Programm Müll verursacht ähnlich wie @Der flotte Johann beschreibt.
    Und Daten werde da auch gelesen wie @tragl. Zeitpunkt des Absturz ist auf jeden Fall so selten das kein Muster erkennbar ist.

    Ich werde mit den Eindrücken einmal schauen ob ich was finde, ich lade es später sonst mal doch hoch. Danke soweit

    Haudruferzappeltnoch schrieb:

    Zeitpunkt des Absturz ist auf jeden Fall so selten das kein Muster erkennbar ist.
    Wenn der Absturz in UnhandledExceptions gefangen wird, setze da einen Haltepunkt rein und sieh Dir die Meldung und den StackTrace an.
    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!

    @Bartosz Solche Tests gehören zur Programm-Entwicklung und -Testung.
    Was glaubst Du, wieviele kleine Testprogramme ich schreibe, um einen kleinen Effekt zu untersuchen.
    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!

    tragl schrieb:

    Scheint öfter dann zu passieren, wenn die Verbindung zur Datenbankdatei auf dem Netzlaufwerk zu langsam ist.
    Dann schließt sich das Programm auch einfach ohne Fehlermeldung.


    Passiert bei Datenbankverbindungen ab und an mal. Aus diesem Grund findest du für den Aufbau einer Datenbankverbindung auch keine Beispielcodes ohne Try-Catch außen rum. Weil allgemein bekannt ist, dass dort eine Vielzahl von Fehlern auftreten können und ja sogar in den Standard .NET Framework Klassen gibt es Fehler, die das Programm crashen lassen, ohne eine Meldung auszugeben. Die wirst du aber auch nicht mit dem UnhandledException-EventHandler zu fassen bekommen, weil sie gar nicht erst ins .NET eigene Exception-Handling laufen. Und wenn sie dort nicht landen, dann wird auch keine Unhandled-Exception generiert und kein Event gefeuert, das behandelt werden könnte. Try-Catch regelt an dieser Stelle.

    Ein Computer wird das tun, was du programmierst - nicht das, was du willst.

Facebook
Telefonspende