Objective C: Macht man sowas

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

  • Objective C: Macht man sowas

    Hi,

    das "Problem": Ich lade z.B. in einer Methode Daten. Ich setze den Networkindicator auf visible.

    Nun gibt es mehrere Stellen wo abgebrochen werden muss. Wenn die geladenen Daten nil sind, wenn die deserialisierung in die Hose geht...

    Jedes mal, bevor ich mit return raus gehe, muss ich dran denken, den Networkindicator wieder auszuschalten.

    In einem Kurs den ich bei Java Leuten gehalten habe, wurde gefragt, warum man das nicht mit @try @finally macht. Ist wohl in Java üblich.

    In ObjC nicht, jedenfalls nicht das ich wüsste. Aber dumm ist es irgendwie auch nicht. So wird nicht aus versehen vergessen den Networkindicator auszuschalten, oder was es auch immer so an abschließenden Arbeiten gibt, die man auf alle Fälle machen muss.

    Quellcode

    1. - (void) loadData
    2. {
    3. [[UIApplication sharedApplication] setNetworkActivityIndicatorVisible: YES];
    5. dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
    6. dispatch_async(queue, ^{
    8. @try
    9. {
    10. NSURL *url = [NSURL URLWithString: @"https://itunes.apple.com/lookup?id=396306964&entity=software&country=de"];
    12. NSData *data = [[NSData alloc] initWithContentsOfURL: url ];
    13. if (data == nil)
    14. {
    15. [[[NSException alloc] initWithName: @"LoadError" reason: @"DerGrund" userInfo: nil] raise]; //ARC ist manchmal komisch :-)
    16. }
    18. NSError *error = nil;
    19. NSDictionary *unserialize = [NSJSONSerialization JSONObjectWithData: data
    20. options: 0
    21. error: &error];
    22. if (error != nil)
    23. {
    24. [[[NSException alloc] initWithName: @"DesrializationError" reason: @"DerGrund" userInfo: nil] raise];
    25. }
    27. NSArray *results = [unserialize objectForKey: @"results"];
    28. if (results == nil)
    29. {
    30. [[[NSException alloc] initWithName: @"FormatError" reason: @"DerGrund" userInfo: nil] raise];
    31. }
    33. _data = results;
    34. }
    35. @catch (NSException *exception)
    36. {
    37. // vielleicht schauen ob es unsere ist
    38. NSLog(@"%@", exception);
    39. _data = @[]; // wenns schief geht z.B. auf alle fälle ein leeres Array
    40. }
    41. @finally
    42. {
    43. dispatch_async(dispatch_get_main_queue(), ^{
    45. [[UIApplication sharedApplication] setNetworkActivityIndicatorVisible: NO];
    46. [[self tableView] reloadData];
    47. });
    49. }
    50. });
    51. }
    Alles anzeigen


    Was meint ihr - oder bin ich etwa wieder der Einzige der das nicht so macht ;)

    Gruß
    Manfred
    Seminare, Artikel, Code. ObjectiveCeeds - alles für die Apfelzucht.

  • Es geht jetzt nicht darum, kreative Ideen zu sammeln wie man das jetzt in dem Fall anders machen könnte.

    Wir werten eine Kette von Fehlern/Abbruchbedingungen aus. Bei jedem Abbruch haben wir Aufräumarbeiten die immer gleich sind.

    Ich kann den Networkindicator auch nach NSData *data = [[NSData alloc] initWithContentsOfURL: url ]; einfach ausschalten und gut ist, da brauch ich keinen sendAsynchronousRequest:queue:completionHandler: dafür.


    Aber den Programmablauf quasi über Exceptions zu steuern ist irgendwie ungewohnt. Für mich ist das immer ehr die letzte Möglichkeit gewesen dem Anwender meiner Klasse einen Schuss vor den Bug zu geben.
    Seminare, Artikel, Code. ObjectiveCeeds - alles für die Apfelzucht.

  • wenns schon synchron ist dann würd ich mir den einen teil in eine eigenen methode packen. ist ja auch wiederverwenbar.
    also laden, entpacken deserialisieren, überprüfen und was weiß ich noch alles in eine einzige methode die nach dem anzeigen des indikators aufgerufen wird. sobald die methode durch ist, blendet man ihn wieder aus.
    solcher code ist ja auch meist wiederverwendbar weil man sowas öfter brauchen kann und sich dann schnell per c&p holen kann ohne den ganzen müll bezüglich GUI etc mit drin zu haben ;)

  • Ich finde den Code ziemlich umständlich. Ausnahmen sind ja eher dafür gedacht, über mehrere Aufrufebenen zu einer Fehlerbehandlung zurückzuspringen, und dabei in der Regel den Code leserlicher zu machen. In Deinem Beispiel bringen sie da keine Vorteile. Da würde ich den Kram im @try-Block in eine Methode packen, die entweder das Ergebnis oder einen Fehler liefert, und @try-@catch-@finally durch ein if-else ersetzen.

    BTW: Anstelle von objectForKey: eignet sich an dieser Stelle valueForKey:; da sparst Du Dir ein if... ;)
    „Meine Komplikation hatte eine Komplikation.“

  • Ich persönlich (Java ist Schuld...) mag Exceptions mittlerweile ein wenig lieber als noch vor einem Jahr.
    Sie sind prima, um bei gravierenden Problemen eben nicht allen Kleinkram händisch lösen zu müssen, sondern über den @finally Block trotzdem wichtige Aufgaben ausführen zu können.

    Insofern spricht aus meiner Sicht nichts gegen diesen Einsatz.

    Allerdings finde ich den Ansatz doch eher kontraproduktiv. Exceptions sollen dafür sorgen, dass das Programm ohne Schaden anzurichten beendet wird. Sie abzufangen halte ich für den falschen Weg, weil dann mit einer inkonsistenten Datenstruktur gearbeitet wird.

    Idee: (IDE = Safari, also eher mittelmäßig)

    C-Quellcode

    1. - (void) loadData
    2. {
    3. [[UIApplication sharedApplication] setNetworkActivityIndicatorVisible: YES];
    4. _data = [self arrayFromURL:[NSURL URLWithString: @"https://itunes.apple.com/lookup?id=396306964&entity=software&country=de"]];
    6. dispatch_async(dispatch_get_main_queue(), ^{
    7. [[UIApplication sharedApplication] setNetworkActivityIndicatorVisible: NO];
    8. [[self tableView] reloadData];
    9. });
    10. }
    12. - (NSArray*)arrayFromURL:(NSURL*)theURL {
    13. NSDictionary * unserialized = [self unserializedDictionaryFromURL:theURL];
    14. NSArray * result = [unserialized objectForKey:@"results"];
    15. if(result != nil) {
    16. result = [NSArray array];
    17. }
    18. return result;
    19. }
    21. - (NSDictionary*)unserializedDictionaryFromURL:(NSURL*)theURL {
    22. NSData * dataFromURL = [self dataFromURL:theURL];
    23. NSError *error = nil;
    24. NSDictionary *unserialize = [NSJSONSerialization JSONObjectWithData:dataFromURL options: 0 error: &error];
    25. if(error) {
    26. unserialize = [NSDictionary dictionary];
    27. }
    28. return unserialize;
    29. }
    31. - (NSData*)dataFromURL:(NSURL*)theURL {
    32. NSData *data = [[NSData alloc] initWithContentsOfURL:theURL];
    33. if(data == nil) {
    34. data = [[NSData alloc] init];
    35. }
    36. return data;
    37. }
    Alles anzeigen

    Damit sollten Probleme mit nil ausfallen und egal was passiert, das Rädchen hört auf zu drehen.

    Die Frage ist ja immer, was ein unerwarteter Ausnahmefehler ist.
    Das NSURL Argument könnte nil sein, was definitiv ein Fehler des Programmierers ist. (Gibt es eine Möglichkeit zu verhindern, dass nil übergeben wird, oder muss ich immer manuell eine Exception werfen?)
    Es ist also ein schwerer Ausnahmefehler und muss dem Programmierer Kund getan werden. Und in dem Fall (also eines schweren Ausnahmefehlers) ist es auch völlig wurscht, ob das Rad aufhört zu drehen oder nicht – die App beendet sich.

    Die Seite kann nicht erreicht werden? Das halte ich für keinen schweren Ausnahmefehler. Eher für ein wahrscheinliches Szenario. WLAN weg, Internet aus, Server down...
    Da sollte die App nicht mit einer Exception abschmieren sondern nur einen Infodialog anzeigen (und dann halt die alten Daten zeigen.)

    Die Daten konnten nicht geparst werden? Hat der User eigentlich auch nix mit zu tun. Sagen kann man es ihm ja, aber abschmieren muss es deswegen ja noch lange nicht – er kann ja vermutlich eh nix daran ändern.

    Die Daten sind einfach leer? Kann passieren. Das Script war nicht fertig, URL stimmt nicht, irgendwer hat rumgebastelt...
    Auch das ist kein Grund dafür, die App abschmieren zu lassen.

    Also ich würde es immer durchlaufen lassen und gemäß den Error Handling Guides von Apple eher ein NSError Objekt mitschleppen.
    (Dann natürlich im Rahmen der Codehygiene einfach IMMER das Error-Objekt behandeln. Wenn's nil ist passiert einfach nix.)
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • Exceptions sind in Objective-C/Cocoa kontrakonzeptionell. Sie sind /niemals/ dafür gedacht, einen vorhergesehenen Kontrollfluss zu steuern. Daher stellt sich die Frage nicht. Übrigens neigt Java-Code dazu, so viele Exceptions zu fangen, dass es am Ende eine try-Wüste wird. Charmant sieht das nur im Einzelfall aus. Was ist eigentlich, wenn du es vergisst, eine Exception zu werfen?

    Soooo doof ist ein goto in einem solchen Falle gar nicht. Eine Exception ist schließlich auch ein goto, nur ein goto, dass sich an gar keine Struktur mehr hält, sozusagen das MEGAGOTO!!!!!!!!!

    Aber du hast ein überschaubares Stück Code, das sich überschaubar debuggen lässt. Wenn du vergisst den Indicator wieder auszuschalten, dann gibt es eine ganz einfache Technik: Bug-Fixing. Es ist tatsächlich so, dass man nicht Code so strukturieren kann, dass er garantiert fehlerfrei ist. Und derlei Versuche führen in der Regel auch nur zu Code, der dermaßen kompliziert ist, dass er garantiert nicht fehlerfrei ist. Habe ich gerade erst in einem Projekt beobachten dürfen. Und Stoßtrupp hat mit dem Konzept "Möglichst so kompliziert, dass es keiner mehr beherrscht" eine ganze Sprache entwickelt.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Marco Feltmann schrieb:

    Ich persönlich (Java ist Schuld...) mag Exceptions mittlerweile ein wenig lieber als noch vor einem Jahr.
    Sie sind prima, um bei gravierenden Problemen eben nicht allen Kleinkram händisch lösen zu müssen, sondern über den @finally Block trotzdem wichtige Aufgaben ausführen zu können.

    Insofern spricht aus meiner Sicht nichts gegen diesen Einsatz.

    Allerdings finde ich den Ansatz doch eher kontraproduktiv. Exceptions sollen dafür sorgen, dass das Programm ohne Schaden anzurichten beendet wird. Sie abzufangen halte ich für den falschen Weg, weil dann mit einer inkonsistenten Datenstruktur gearbeitet wird.

    Idee: (IDE = Safari, also eher mittelmäßig)

    C-Quellcode

    1. - (void) loadData
    2. {
    3. [[UIApplication sharedApplication] setNetworkActivityIndicatorVisible: YES];
    4. _data = [self arrayFromURL:[NSURL URLWithString: @"https://itunes.apple.com/lookup?id=396306964&entity=software&country=de"]];
    6. dispatch_async(dispatch_get_main_queue(), ^{
    7. [[UIApplication sharedApplication] setNetworkActivityIndicatorVisible: NO];
    8. [[self tableView] reloadData];
    9. });
    10. }
    12. - (NSArray*)arrayFromURL:(NSURL*)theURL {
    13. NSDictionary * unserialized = [self unserializedDictionaryFromURL:theURL];
    14. NSArray * result = [unserialized objectForKey:@"results"];
    15. if(result != nil) {
    16. result = [NSArray array];
    17. }
    18. return result;
    19. }
    21. - (NSDictionary*)unserializedDictionaryFromURL:(NSURL*)theURL {
    22. NSData * dataFromURL = [self dataFromURL:theURL];
    23. NSError *error = nil;
    24. NSDictionary *unserialize = [NSJSONSerialization JSONObjectWithData:dataFromURL options: 0 error: &error];
    25. if(error) {
    26. unserialize = [NSDictionary dictionary];
    27. }
    28. return unserialize;
    29. }
    31. - (NSData*)dataFromURL:(NSURL*)theURL {
    32. NSData *data = [[NSData alloc] initWithContentsOfURL:theURL];
    33. if(data == nil) {
    34. data = [[NSData alloc] init];
    35. }
    36. return data;
    37. }
    Alles anzeigen

    Damit sollten Probleme mit nil ausfallen und egal was passiert, das Rädchen hört auf zu drehen.

    Die Frage ist ja immer, was ein unerwarteter Ausnahmefehler ist.
    Das NSURL Argument könnte nil sein, was definitiv ein Fehler des Programmierers ist. (Gibt es eine Möglichkeit zu verhindern, dass nil übergeben wird, oder muss ich immer manuell eine Exception werfen?)
    Es ist also ein schwerer Ausnahmefehler und muss dem Programmierer Kund getan werden. Und in dem Fall (also eines schweren Ausnahmefehlers) ist es auch völlig wurscht, ob das Rad aufhört zu drehen oder nicht – die App beendet sich.

    Die Seite kann nicht erreicht werden? Das halte ich für keinen schweren Ausnahmefehler. Eher für ein wahrscheinliches Szenario. WLAN weg, Internet aus, Server down...
    Da sollte die App nicht mit einer Exception abschmieren sondern nur einen Infodialog anzeigen (und dann halt die alten Daten zeigen.)

    Die Daten konnten nicht geparst werden? Hat der User eigentlich auch nix mit zu tun. Sagen kann man es ihm ja, aber abschmieren muss es deswegen ja noch lange nicht – er kann ja vermutlich eh nix daran ändern.

    Die Daten sind einfach leer? Kann passieren. Das Script war nicht fertig, URL stimmt nicht, irgendwer hat rumgebastelt...
    Auch das ist kein Grund dafür, die App abschmieren zu lassen.

    Also ich würde es immer durchlaufen lassen und gemäß den Error Handling Guides von Apple eher ein NSError Objekt mitschleppen.
    (Dann natürlich im Rahmen der Codehygiene einfach IMMER das Error-Objekt behandeln. Wenn's nil ist passiert einfach nix.)

    So ist es in Cocoa gedacht. Wobei das Mitschleppen zunehmend einfach wird, weil bei den weiteren Methoden einfach **error durchgereicht werden kann.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?