Ich programmiere verschiedene Routinen und ich versuche mein Bestes, um es sauber und refaktoriert zu halten.
Methoden, die ich erstelle, fangen an, diesem Code ähnlich zu sehen:
%Vor%Ich liebe NSError, aber das scheint eine furchtbar plumpe Art zu sein, alle meine Fehler zu behandeln.
Ein paar Gedanken, die ich über alternative Wege hatte:
a) Die Fehlerüberprüfung könnte in die Methoden doSomething, doSomethingElse etc. eingebaut werden, aber dann wäre ich nicht in der Lage, die Button-Press-Methode zu verlassen, ohne den Rückgabewert zu überprüfen eine ähnliche Struktur.
b) Ich könnte den NSE-Fehler als "Schlüsselwert beobachtet" definieren, aber etwas darüber fühlt sich zutiefst falsch an. Ich bin mir der Möglichkeiten von Missbrauch mit KVO sehr bewusst, also versuche ich alles ohne es zu machen, wo immer es möglich ist.
Sicher fehlt mir hier etwas wirklich Grundlegendes? Gibt es ein Muster, das mir helfen kann? Oder ist diese Struktur in Ordnung?
Ich denke, dass keine der hier vorgestellten Antworten Apple's empfohlene Praktiken berücksichtigt.
Grundsätzlich sollten Sie nie nach dem Objekt NSError suchen, um festzustellen, ob ein Problem aufgetreten ist. Sie überprüfen, ob ein Problem aufgetreten ist, indem Sie den Wert überprüfen, der von der Methode zurückgegeben wird, die einen Zeiger auf einen Zeiger auf NSError verwendet.
Von der Apple-Dokumentation :
Wichtig Erfolg oder Fehlschlag wird durch den Rückgabewert des Methode. Obwohl Cocoa-Methoden Fehlerobjekte indirekt zurückgeben Die Cocoa - Fehlerdomäne gibt solche Objekte garantiert zurück, wenn der Methode zeigt einen Fehler an, indem Sie
niloderNOdirekt zurückgeben Überprüfen Sie immer, ob der RückgabewertniloderNOvor dem Versuch ist Mach etwas mit dem ObjektNSError.
Der Kern Ihrer Frage ist, ob Sie strukturelle Verbesserungen an Ihrer Fehlerbehandlung vornehmen können. Ich denke schon, indem ich im Wesentlichen mehr Ebenen der Verschachtelung einführe, entweder durch Extrahieren von mehr Code in separate Methoden / Funktionen oder durch Einfügen von Verschachtelung in Ihre High-Level-Beispielmethode.
Die Idee ist, wenn Sie die meisten Fehler behandeln, sind Sie wahrscheinlich entweder daran interessiert, eine alternative Aufgabe auszuführen oder den Fehler in der Kette zu wiederholen und weiterzugeben, sodass ein verantwortlicher Controller den Fehler über die Benutzeroberfläche an den Benutzer übermitteln kann .
Mit dieser Idee von "propagate oder handle" würde ich Ihre Beispielmethode folgendermaßen umschreiben:
%Vor%Beachten Sie, dass es gute Argumente dafür gibt, zu viel Verschachtelung in eine bestimmte Methode einzuführen. Eine solche Verschachtelung ist im Wesentlichen eine kurze Alternative zum Extrahieren von Methoden. Es kann zum Beispiel sinnvoller sein, dass "doSomething:" selbst doSomethingElse: aufruft, das doYetSomethingElse aufruft: zum Beispiel. Dies würde dem Code die gleiche Struktur wie das if-nest auferlegen, wäre aber wohl wartungsfreundlicher.
Abgesehen davon bin ich kein Fan von Inline-Return-Statements. In dieser bestimmten Instanz ruft die Beispielmethode keinen Rückgabewert auf, aber wenn dies der Fall ist, wird eine lokale Variable am Rückgabewert festgelegt und erst am Ende der Ablaufsteuerung zurückgegeben. Das vorzeitige Aufspringen einer Funktion oder Methode ist ein sicherer Weg, um seltsame Bugs zu entdecken, IMHO.
Ich denke, die wirkliche Frage ist, wie viel Granularität Sie in Ihrer Fehlerbehandlung benötigen. Ihr Code ist grundsätzlich korrekt - aber Sie können Dinge aufräumen, indem Sie weniger häufig auf Fehler prüfen oder einen Ansatz wie Teabot verwenden, der in seiner Antwort mit NSException erwähnt wird. Viele der integrierten Funktionen, die Fehler zurückgeben (wie zB moveItemAtPath :) von NSFileManager, geben zusätzlich zu einem NSError-Objekt ein BOOL zurück - Sie können also auch verschachtelte if-Anweisungen verwenden, wenn Sie die NSError-Informationen nicht benötigen.
>Alles in allem, es gibt wirklich keine großartige Möglichkeit, dies zu tun. Wenn Ihr Code lang ist, könnte KVO eine coole Lösung sein. Ich habe es jedoch nie für eine solche Situation ausprobiert.
Hinweis: Als ich dies veröffentlichte, war mir keine Debatte über MacOS / Cocoa-Ausnahmen bekannt. Bitte beachten Sie dies, wenn Sie diese Antwort in Betracht ziehen.
Warum nicht stattdessen Ausnahmen ? Dadurch können Sie auf den Fehlerparameter Ihrer Methoden verzichten und Ihre Fehler an einer Stelle behandeln.
%Vor%Sie müssen natürlich Ausnahmen innerhalb Ihrer doXXXX-Methoden auslösen:
%Vor%Tags und Links objective-c cocoa error-handling oop