Suchergebnisse

Diese Einstellungen erzeugen im My Project-Ordner eine Setings.settings die xml-artig diese Werte speichert. Außerdem wirds nochmal in die App.config geschrieben, was ich nicht ganz verstehe, warum man das zweimal braucht. Und beim Kompilieren wandert es dann in die 'Projektname'.dll.config im Build-Ordner (das ist dann eine Kopie der App.config)

Zitat von Amelie: „Nein, weil ich noch nicht weiß wie ich da mal einen Fehler produzieren kann.“Entweder du schreibst ein Throw New Exception an die Stelle die dich interessiert, dann könntest du aber genauso gut den Try-Block durch den Catch-Block ersetzen Oder du ziehst mal die Berechtigungen aus dem XmlFilePath, Oder wenn der XmlFilePath nach extern geht, könntest du ein Kabel ziehen. Aber bei Laden oder Speichern von ordentlichen Anwendungs-Settings sind Exceptions eher unwahrscheinlich bzw.…

Zitat von RodFromGermany: „Wozu? Da wäre doch ein Haltepunkt effektiver“Ein Haltepunkt allein, wäre vollständig wirkungslos bei dem Thema, auf das ich geantwortet gehabt hatte, denn der wird dich nicht vom Try in den Catch Block wechseln lassen. Aber ja etwas so ähnliches habe ich direkt im Anschluss vorgeschlagen. Da ist ein Haltepunkt aber auch nicht nötig, es geht ja erstmal ums Ergebnis, debuggt wird erst wenns nicht stimmt.

Zitat von Amelie: „eine andere Exception“eine andere als was? Bisher haben wir nie von einer spezifischen Exception gesprochen.

Na in der GetEnvironmentData wird doch nur diese SaveSettings Methode aufgerufen, die anderen Zeilen sind nur Zuweisungen. Und Exceptions knallen generell erstmal in der untersten Schublade. Und wenn du die in so einer Schublade schon abfänst, dann ist weiter oben wieder alles frisch. Machst du in SaveSettings das Try Catch weg, greift Catch ne Ebene weiter oben