Fehlerbehandlung beim Datei einlesen

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Fehlerbehandlung beim Datei einlesen

    Die ersten Schritte in Swift sind doch holpriger als gedacht :(

    Folgende Funktion wird beim Programmstart aufgerufen ;

    Quellcode

    1. func applicationDidFinishLaunching(aNotification: NSNotification) {
    2. // Insert code here to initialize your application
    3. do {
    4. try self.d65Einlesen();
    5. }
    6. catch _ {
    7. // Fehlermeldung
    8. }
    9. }
    10. .....
    11. func d65Einlesen() throws{
    12. d65 = NSArray(contentsOfFile: NSBundle.mainBundle().pathForResource("d65", ofType: "plist")!)
    13. }
    Alles anzeigen
    Wenn die Datei beschädigt ist oder nicht existiert, führt dies natürlich zu einem fatalen Fehler.
    Ich habe mich jetzt mit try, catch, throws... versucht (siehe oben) aber ich fange den Fehler nicht ab. Irgendwas grundsätzliches mache ich wohl falsch .

    Wie kann ich diesen Fehler abfangen?

    Hans

  • Du müßtest in func d65Einlesen() throws im Fehlerfall dann auch Deine Exception produzieren. Z.B.:

    Quellcode

    1. func d65Einlesen() throws{
    2. d65 = NSArray(contentsOfFile: NSBundle.mainBundle().pathForResource("d65", ofType: "plist")!)
    3. if d65 == nil {
    4. throw NSError(domain: "errordomain", code: -1, userInfo: nil)
    5. }
    6. }
    Im übrigen sind explicitly unwrapped optionals aka ! immer eine beliebte Fehlerquelle. Am besten gar nicht erst verwenden.

    Mit dem Unterstrich in catch _ { } sagst Du außerdem, daß Du die Exception ignorieren willst, bzw. daß das Fehlerobjekt keiner Variable zugewiesen wird.

  • @tsunamix :

    Dein Vorschlag geht bei mir nicht. Die direkte Zuweisung des Dateiinhalts einer nicht-existenten Datei ans Array führt zum Absturz.
    Es funktioniert nur, wenn ich splitte und die Fehlerabfrage (wie von Dir beschrieben) auf den Datei-String beziehe.
    .

    Quellcode

    1. let datei = NSBundle.mainBundle().pathForResource("D65" ofType: "plist")
    2. if datei == nil
    4. usw...
    Bei meiner if-let Lösung ist es aber dasselbe Problem.

  • Nur so als kleine Anmerkung. Du kannst guard let-Statements auch 'verketten'. Z.B:

    Quellcode

    1. func d65Einlesen() throws {
    2. guard
    3. let d65Path = NSBundle.mainBundle().pathForResource("D65", ofType: "plist"),
    4. let d65 = NSArray(contentsOfFile: d65Path)
    5. else {
    6. throw NSError(domain: "domain", code: -1, userInfo: nil)
    7. }
    8. // hier mit d65 weiterwerkeln
    9. }

  • HansGerber schrieb:

    :) Das stimmt schon. Aber so kann ich wenigstens eine Fehlermeldung zeigen, an was es liegt.
    Ein kommentarloser Absturz ist irgendwie unschön und wenig aufschlussreich.
    Ich behaupte mal, dass du das gar nicht willst, da dieser Fehler beim Nutzer niemals auftreten darf, und auch eine kaputte App sollte dort nicht (weiter-)laufen.
    1. Wenn auf deinem Entwicklungssystem der Fehler auftritt, ist ein App-Absturz optimal. Du bist erstens gezwungen den Fehler sofort zu beheben und zweitens siehst du am Stacktrace im Debugger sofort wo der Fehler herkommt.
    2. Wenn der Fehler dennoch beim Nutzer auftreten sollte. Bekommst du sofort in Form von Crash-Logs Rückmeldung von deinen Nutzern. Mit den Crash-Logs findest du zumindest die Stelle. Auf detaillierte Kommentare mit Fehlerbeschreibungen kannst du hingegen lange warten.
    Fall 2 dürfte aber so gut wie nie auftreten. Dafür sorgt ja Fall 1. ;) Und wenn du den Fehler übersiehst, gibst ja immer noch den App-Review, die dir in diesem Fall den CrashLog senden. ;)
    „Meine Komplikation hatte eine Komplikation.“

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von macmoonshine ()

  • macmoonshine schrieb:

    Wobei in diesem Fall die App eigentlich immer abstürzen sollte.
    Sehe ich genauso: Lieber ein Ende mit Schrecken, als ein Schrecken ohne Ende. Ganz fatal wird's wenn man versucht solche Situationen zuzukleistern und dadurch z.B. die Integrität deines Datenmodells abhanden kommt und dann in der Anwendung ominöse Fehler an ganz anderen Stellen auftreten auf deren wahre Ursache Du nur schwer kommst.