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

  • zerm schrieb:

    Amin Negm-Awad schrieb:

    http://www.stroustrup.com/3rd_safe.pdf

    Ah danke. In E.3.2 erklärt er ja gleich, dass man mit RAII das ganze relativ gut in den Griff bekommt. Ich persönlich finde das alles so auch relativ "selbstverständlich" so - ist halt wahrscheinlich auch eine Sache, wie sehr man "in C++ denkt".

    Man bekommt auch Error-Handling gut in den Griff. Ich persönliche finde das alles so auch relativ "selbstverständlich" – ist halt wahrscheinlich auch eine Sache, wie sehr man "in Objective-C denkt".
    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"?

  • Amin Negm-Awad schrieb:

    Das Problem hast du aber auch mit Error-Handling. Das ist ja ein logisches Problem.


    Ich habe nicht gesagt, dass man das Problem mit Error-Handling nicht hat und ich wollte es auch nicht implizieren. Mein Post sollte eher aufzeigen, dass Exception Safety nicht nur Ressourcen betrifft. Wenn ich Code schreibe, dann mache ich das im Allgemeinen ohne darauf zu achten, ob der Code nun Exception-Safe ist oder nicht. Am Ende des Tages ist mein Code zu 99% nicht exception-safe. RAII ändert daran herzlich wenig.
    Die Objective-Cloud ist fertig wenn sie fertig ist. Beta heißt Beta.

    Objective-C und Cocoa Band 2: Fortgeschrittene
    Cocoa/Objective-C Seminare von [co coa:ding].

  • zerm schrieb:

    Amin Negm-Awad schrieb:

    Man bekommt auch Error-Handling gut in den Griff. Ich persönliche finde das alles so auch relativ "selbstverständlich" – ist halt wahrscheinlich auch eine Sache, wie sehr man "in Objective-C denkt".

    Schön, dann ist ja jeder mit seiner Sprache glücklich! :)

    Du hattest ja gesagt, dass du den Thread nur quergelesen hast. Hier fällt es dann auf.

    Es geht nicht darum, ob jeder glücklich ist, sondern darum, ob Exceptions das Leben vereinfachen. Und da ist "Jeder ist glücklich" ziemlich nah an "Nein".
    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"?

  • Amin Negm-Awad schrieb:

    Es geht nicht darum, ob jeder glücklich ist, sondern darum, ob Exceptions das Leben vereinfachen. Und da ist "Jeder ist glücklich" ziemlich nah an "Nein".

    Ich wollte eigentlich einer weiteren Diskussion aus dem Weg gehen, weil ich denke, dass es zu nichts führt. Ich bin mit Exceptions glücklicher und für mich, bei meiner täglichen Arbeit, vereinfachen sie mir mein Leben - Insbesondere helfen sie mir, wie ich finde, Code sehr robust zu bekommen, was bei mir häufig ein sehr wichtiges Kriterium ist. Natürlich kann man das anders sehen, und einige Probleme, die Exceptions für C++ lösen, existieren in dieser Form gar nicht in Objective-C - und ich würde auch nicht behaupten, dass Objective-C mit Exceptions besser wäre. Von daher finde ich eine pauschale Aussage auch gar nicht angebracht.

    Davon abgesehen ging unsere unmittelbar letzte Diskussion doch darum, dass Du (eventuelle) Probleme im Exception-Handling in C'tors nicht als selbstverständlich empfunden hattest, ich jedoch - da ich C++ gewohnt bin - schon als sehr naheliegend. Hingegen finde ich Error-Handling in Obj-C nicht ganz intuitiv, aber das siehst Du natürlich anders. Daher habe ich mich gefreut, dass wir scheinbar beide zufrieden sind mit dem, was wir tun.
    ♥C++

  • Wenn es auf ein "gefühlt einfacher" hinausläuft, das sich ganz offenkundig aus einem jeweiligen Gewöhnungsvorsprung begründet, ist damit nichts in der Diskussion erreicht außer der selbstverständlichen Erkenntnis, dass man mit dem am Besten zurechtkommt, was man am besten kennt.

    Also anders: Die von mir angesprochenen "Probleme" bei Konstruktion und Dekonstruktion (auch das hatte ich erwähnt) sind zusätzliche Probleme, die hinzutreten. Bei Error-Handling gibt es keine offenkundig von Stoßtrupp für erörterungsbedürftig gefundene Besprechung für Konstruktoren, die man dann aber in einerm weietren Abschnitt vereinfachen kann. Errors sind Errors, egal wo. Bei Dekonstruktoren gibt es keine zusätzliche Regel, dass Errors nicht auftreten können. Errors sind Errors, egal wo.

    Bei Error-Handling mag manches einen Schlenker mehr machen und daher einen zusätzlichen Aufwand bedeuten, aber es gibt keine zusätzlichen Regeln. Das scheint mir ganz jenseits von Gewohnheiten und Gewöhnungen ein objektives Kriterium der Komplexität zu sein, auch wenn man sich an die zusätzlichen Regeln gewöhnt hat. Regeln, die einem ins Blut übergegangen sind, mögen einfach erscheinen. Keine Regeln beachten zu müssen, ist objektiv einfacher.

    * Beides hängt natürlich auch damit zusammen, dass Konstruktion und Dekonstruktion in C++ Sprachbestandteil sind, während jedenfalls die Konstruktion in Objective-C über das Framework "im normalen Gang" abgewickelt werden. Insofern wäre es spannend, genauer zu untersuchen, welche Probleme der Kontruktion und Dekonstruktion mit dem Speicherverwaltungsmodell von Objective-C kombiniert mit dem Excpetionsmodell von C++ ergeben. Mag jemand seine Diplomarbeit damit verbringen.
    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"?

  • Zu einem gewissen Grad hast Du natürlich recht - da ich aber die "Probleme" sehr gut kenne und der Mehraufwand sich in der Praxis extrem in Grenzen hält (bzw. global gesehen geringer ist), finde ich, dass die Vorteile deutlich überwiegen. Ich gehe auch soweit mit, dass Exceptions nicht "perfekt" sind, sonst wäre die Diskussion schnell zu ende. Jedoch ist meiner Erfahrung nach C++ Code mit strikter und korrekter Verwendung von Exceptions einfacher zu lesen, zu schreiben und zu warten, als solcher ohne.

    Ich hab in Büchern schon ganze Kapitel zu dem Thema gelesen, und das wird immer eine Diskussionsgrund sein, daher denke ich nicht, das wir es schaffen werden, hier zu einem Konsens zu kommen. Immerhin sind wir uns einig, dass es korrekt Fehlerbehandlung braucht - sei es über Exceptions oder über explizites Prüfen (nach jedem Call) und beides hat seine Vor- und Nachteile (die in der entsprechenden Literatur ausreichend zu finden sind).

    Eine kleine Anmerkung zum expliziten Prüfen: Angenommen, Du hast in Obj-C in Deinem -init etwas wie
    _array=[NSArray arrayWithObjects:[Foo fooWithInt:1],[Foo fooWithInt:2],nil];
    Falls fooWithInt einmal fehlschlägt, oder arrayWithObjects auf Grund von Out-of-memory fehlschlägt, ist dein array entweder unvollständig, oder nil. Prüfst Du tatsächlich jedesmal? Eine Exception an dieser Stelle bringt mir immerhin im schlechtesten Fall einen terminate vom Prozess, aber ich konstruiere kein "fehlerhaftes" Objekt, mit dem ich unter Umständen fehlerhaft weiterarbeite.
    ♥C++

  • Woher weißt Du denn, das dein Objekt unvollständig ist? ;)
    Wenn fooWithInt fehl schlägt und nil zurück liefert, ist das Array unvollständig. Wenn fooAtIndex fehl schlüge, gäbe es eine OutOfBoundsException.
    Wie dem auch sei, wenn das zurückgegebene Array nil ist, dann ist das halt so. Die Nachrichten an nil sind ja erlaubt.
    Abgesehen davon, dass dem User einige Daten nicht angezeigt werden, kann nix passieren.

    Mag sein, dass der User das doof findet. Besser als eine instabile Anwendung ist es allemal.
    «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

  • zerm schrieb:


    Eine kleine Anmerkung zum expliziten Prüfen: Angenommen, Du hast in Obj-C in Deinem -init etwas wie
    _array=[NSArray arrayWithObjects:[Foo fooWithInt:1],[Foo fooWithInt:2],nil];
    Falls fooWithInt einmal fehlschlägt, oder arrayWithObjects auf Grund von Out-of-memory fehlschlägt, ist dein array entweder unvollständig, oder nil. Prüfst Du tatsächlich jedesmal? Eine Exception an dieser Stelle bringt mir immerhin im schlechtesten Fall einen terminate vom Prozess, aber ich konstruiere kein "fehlerhaftes" Objekt, mit dem ich unter Umständen fehlerhaft weiterarbeite.


    Das Problem was du damit hast ist das du dir eine Klasse baust die dein Programm abschießen kann und deren Fehler nicht behandelbar sind:

    Mac Developer Library schrieb:


    The Cocoa frameworks are generally not exception-safe. The general pattern is that exceptions are reserved for programmer error only, and the program catching such an exception should quit soon afterwards.


    Ich würde so etwas nur machen um auf falsche Parameter zu reagieren (was die aufrufende Methode durch Prüfung vermeiden kann), nicht aber zur generellen Fehlerbehandlung.