Hallo zusammen,
ich verwende eine externe Bibliothek, die zurzeit unter bestimmten Umständen eine "StackOverflowException" wirft.
Leider habe ich bisher nicht rausgefunden, wie ich in meiner Anwendung hier rauf reagieren kann (try-catch fängt diese Exception ja nicht).
Im Moment stürzt mir immer die ganze Anwendung ab, wenn dieser Fall eintritt.
Kann mir jemand helfen?
Gruß
Christoph
Stackoverflow (und auch MemoryOverflow) kann man nicht abfangen.
Da der Stack recht groß ist kommt der Stackoverflow meistens durch unendliche Rekursion zustande.
Prüf das mal.
Man kann aber Stackgröße und Speicherverbrauch prüfen und eine Meldung bringen "Programm bitte neu starten" wenn die Werte zu groß sind. So stürzt die Anwendung nicht ab und dem Anwender gehen keine Daten verloren.
Ich habe das mal so gemacht bis ich ein Memory Leak in der Winforms Anwendung entdeckt habe.
Grüße Bernd
Workshop : Datenbanken mit ADO.NET
Xamarin Mobile App : Finderwille Einsatz App
Unternehmenssoftware : Quasar-3
Danke für die Antwort.
Ich habe ja das Problem, dass es sich bei der betroffenen Library um eine externe Library handelt, die beim Aufrufen einer Funktion StackOverflowException wirft.
Daher kann ich hier nicht wirklich viel analysieren.
Das ist der Nachteil wenn man externe Bibliotheken verwendet.
Da macht man folgendes :
Grüße Bernd
Workshop : Datenbanken mit ADO.NET
Xamarin Mobile App : Finderwille Einsatz App
Unternehmenssoftware : Quasar-3
Du könntest auch einen Wrapper entwickeln und als eigenen Prozess laufen lassen.
Wäre zwar eine ganze Ecke mehr Arbeit, weil Du ja auch mit dem Prozess kommunizieren musst, aber dann schmiert nur der zweite Prozess ab.
Den Prozess kannst Du dann überwachen und beim Absturz entsprechend reagieren.
Bei häufiger genutzten Bibliotheken halte ich aber die Gefahr für sehr groß, dass der Fehler im eigenen Code liegt.
Daher:
Schauen ob es ein Update der Bibliothek gibt
Versuchen den Fehler einzugrenzen
Schauen ob jemand anders den Fehler auch hat
Wären meine ersten Schritte
NuGet Packages im Code auslesen
lock Alternative für async/await
Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.
Daher kann ich hier nicht wirklich viel analysieren.
Das stimmt so nicht.
a) wenn die Bibliothek offen ist, dann kannst einfach den im Code suchen
b) wenn die Bibliothek geschlossen ist, es aber ein gravierender Fehler für Dich ist, darfst die Bibliothek dekompilieren und den Fehler fixen => EuGH: Recht auf Reverse Engineering zur Fehlerkorrektur | heise online
Kann auch gut sein, dass das einfach nen Fehler ist, für den Du verantwortlich bist, weil Du die Bibliothek falsch verwendest.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
Hallo Christoph K.,
ergänzend zu Palladin007s Antwort, falls dein Projekt auf dem klassischen .NET Framework (also vor .NET Core) basiert, kann statt einem extra Prozess auch eine eigene AppDomain verwendet werden.
Das Problem bei Stackoverflow-Fehlern ist dass der (welch Überraschung) der Stackspace aufgebraucht ist. Würde nun diese Exception fangbar sein, so müsste auch ein Ex-Handler laufen und das wäre im Stack, der aber eben keinen Platz mehr hat. Also kann der Ex-Handler nicht laufen und das Ergebnis ist der App-Crash (korrekterweise).
Würde .NET z.B. extra Platz am Stack frei halten, so hilft das auch nicht viel falls der SO außerhalb von .NET passiert. Abgesehen davon dass es mehr verkomplizieren würde ohne wirklichen Nutzen.
mfG Gü
Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.
"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"
Oder du wechselst auf .NET Framework <2.0. Damals war es nöch möglich StackOverflow Exceptions zu catchen.
(Ironie...)
cSharp Projekte : https://github.com/jogibear9988