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

  • Amin Negm-Awad schrieb:

    Es gibt ja noch den umgekehrten Fall der Exception während einer Objektkonstuktion, bei der bereits Objekte konstruiert wurden. In C++ muss man AFAIK alle Exceptions fangen, wenn das Stack-Unwinding funktionieren soll. zermelo weiß sicherlich Genaueres.

    Ich weiss nicht genau, was Du meinst, hab den Thread aber zugegebenermassen nur überflogen (weil ich mir dachte, wie schön es ist, solche Probleme in C++ dank RAII nicht zu haben). Exceptions bei der Konstruktion sind aber, sofern man RAII beachtet, natürlich auch kein Problem, und man braucht im c'tor auch nichts zu fangen damit das korrekt funktioniert.

    Amin Negm-Awad schrieb:

    Ich weiß jetzt nicht aus dem Effeff, ob fclose() eine Exception werfen kann, mutmaße es aber. Stellen wir uns das mal vor.

    fclose() ist C. Das wirft nichts?

    Amin Negm-Awad schrieb:

    Jetzt wird das Objekt möglicherweise dekonstruiert, weil eine Exception geflogen kam. Dann kann die Dekonstruktion jetzt wieder eine Exception werfen. Die muss ich fangen.

    Eine der wenigen tatsächlich notwendigen Konventionen in C++ verbietet das Werfen von Exceptions im Destruktor. Jeder ordentlich C++ Programmierer hält sich dadran und es ist mir tatsächlich noch nie etwas Gegenteiliges untergekommen (Code, der das macht, kann man gleich aussortieren. Da wird auch sonst nichts brauchbares drin sein).
    ♥C++

  • wolf_10de schrieb:

    zerm schrieb:

    fclose() ist C. Das wirft nichts?

    Doch 0 oder EOF

    Nee, das wird zurückgegeben, nicht geworfen. Gravierender Unterschied. :)
    «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:

    Amin Negm-Awad schrieb:

    Es gibt ja noch den umgekehrten Fall der Exception während einer Objektkonstuktion, bei der bereits Objekte konstruiert wurden. In C++ muss man AFAIK alle Exceptions fangen, wenn das Stack-Unwinding funktionieren soll. zermelo weiß sicherlich Genaueres.

    Ich weiss nicht genau, was Du meinst, hab den Thread aber zugegebenermassen nur überflogen (weil ich mir dachte, wie schön es ist, solche Probleme in C++ dank RAII nicht zu haben). Exceptions bei der Konstruktion sind aber, sofern man RAII beachtet, natürlich auch kein Problem, und man braucht im c'tor auch nichts zu fangen damit das korrekt funktioniert.

    Amin Negm-Awad schrieb:

    Ich weiß jetzt nicht aus dem Effeff, ob fclose() eine Exception werfen kann, mutmaße es aber. Stellen wir uns das mal vor.

    fclose() ist C. Das wirft nichts?

    Amin Negm-Awad schrieb:

    Jetzt wird das Objekt möglicherweise dekonstruiert, weil eine Exception geflogen kam. Dann kann die Dekonstruktion jetzt wieder eine Exception werfen. Die muss ich fangen.

    Eine der wenigen tatsächlich notwendigen Konventionen in C++ verbietet das Werfen von Exceptions im Destruktor. Jeder ordentlich C++ Programmierer hält sich dadran und es ist mir tatsächlich noch nie etwas Gegenteiliges untergekommen (Code, der das macht, kann man gleich aussortieren. Da wird auch sonst nichts brauchbares drin sein).

    Es geht ja nicht darum, dass man sich daran halten kann oder dies tut. Man kann sich auch an das Error-Pattern halten und jeder ordentliche Objective-C-Porgrammierer wird das tun. Es geht darum, ob das höhere Komplexität verursacht oder geringere.

    Wenn du keine Exception in ~ werfen darfst, musst du alle fangen, die das, was du im ~machst, verursachen können. Das Problem verschiebt sich also.
    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:

    Wenn du keine Exception in ~ werfen darfst, musst du alle fangen, die das, was du im ~machst, verursachen können. Das Problem verschiebt sich also.

    Naja...
    Wenn man davon ausgehen kann, dass nur mit Exceptions und Subklassen um sich geworfen wird, braucht man nur die Exception zu fangen und zu ignorieren. Dies schließt ja Subklassen ein.
    Da C++ aber offenbar mit allem um sich werfen kann (Integer zum Beispiel), wird es dann doch etwas Aufwand.
    «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

  • Amin Negm-Awad schrieb:

    Wenn du keine Exception in ~ werfen darfst, musst du alle fangen, die das, was du im ~machst, verursachen können. Das Problem verschiebt sich also.

    Theoretisch schon. Praktisch ist das Exception-handling in C++ üblicherweise relativ schlank. Sehr selten habe ich überhaupt try/catch in einem d'tor, und wenn, dann (wie sonst auch) sehr lokalisiert.

    Marco Feltmann schrieb:

    Da C++ aber offenbar mit allem um sich werfen kann (Integer zum Beispiel), wird es dann doch etwas Aufwand.

    Ja kann. Macht aber keiner. Zumindest niemand, der das ganze ernsthaft betreibt.

    Amin Negm-Awad schrieb:

    In E.3.1. sieht das aber mit den Exceptions in Konstruktoren nicht so selbstverständlich einfach aus.

    Ich weiss nicht, worauf Du dich mit E.3.1. beziehen willst. Im C++03, 15.2 (Exceptions ins C'tors) ist das eigentlich relativ simpel. Inklusive der Hinweise, im D'tor bitte nichts hinauszuwerfen.
    ♥C++

  • zerm schrieb:

    Amin Negm-Awad schrieb:

    Wenn du keine Exception in ~ werfen darfst, musst du alle fangen, die das, was du im ~machst, verursachen können. Das Problem verschiebt sich also.

    Theoretisch schon. Praktisch ist das Exception-handling in C++ üblicherweise relativ schlank. Sehr selten habe ich überhaupt try/catch in einem d'tor, und wenn, dann (wie sonst auch) sehr lokalisiert.

    Marco Feltmann schrieb:

    Da C++ aber offenbar mit allem um sich werfen kann (Integer zum Beispiel), wird es dann doch etwas Aufwand.

    Ja kann. Macht aber keiner. Zumindest niemand, der das ganze ernsthaft betreibt.

    Amin Negm-Awad schrieb:

    In E.3.1. sieht das aber mit den Exceptions in Konstruktoren nicht so selbstverständlich einfach aus.

    Ich weiss nicht, worauf Du dich mit E.3.1. beziehen willst. Im C++03, 15.2 (Exceptions ins C'tors) ist das eigentlich relativ simpel. Inklusive der Hinweise, im D'tor bitte nichts hinauszuwerfen.

    Oben: So schlank wie Error-Handling in Objective-C/Cocoa. Das hängt ja von der Zahl der möglichen Fehlerfälle, nicht von deren Behandlung ab. Deshalb taugt es nicht als Unterscheidungsmerkmal.

    Unten: Stoßtrupps Elaborat hat einen Anhang E für Exception-Handling.
    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"?

  • Leute habt ihr euch mal den Wikipediaartikel zu RAII durchgelesen? Entweder verstehe ich den nicht oder er ist Mist. Ich zitiere:

    RAII is vital in writing exception-safe C++ code: to release resources before permitting exceptions to propagate (in order to avoid resource leaks) one can write appropriate destructors once rather than dispersing and duplicating cleanup logic between exception handling blocks that may or may not be executed.


    Exception safety ist doch mehr als nur "alle betroffenen Ressourcen werden bei einer Exception wieder freigegeben". Oder? Dass Ressourcen wieder freigeben werden ist ohne Zweifel sehr wichtig aber das ist doch noch längst nicht das Einzige, was nötig wäre. Stellt euch mal vor ich iteriere über ein Array und manipuliere die Objekte. Bei der 2149012840912842019'sten Iteration wird eine Exception geworfen. Code, der 100% Excetion safe ist würde nun die 2149012840912842019 Iterationen wieder "Rückgängig" machen. Entweder durch eine "kluge", nicht zu verallgemeinerbare Logik oder durch eine Deep-Copy der Arrays:

    Quellcode

    1. foreach element in array do
    2. modify(element);
    3. end


    Wäre nicht Exception safe: Es würden bei RAII zwar alle Ressourcen freigegeben (falls nötig) aber array wäre anschließend ggf. kaputt. Naive Lösung:

    Quellcode

    1. array2 = deep_copy_of(array) // ggf. sehr Zeit + Ressourcenintensiv
    2. try
    3. foreach element in array do
    4. modify(element);
    5. end
    6. catch
    7. // rücksetzen
    8. array = array2;
    9. free(array);
    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].

  • wolf_10de schrieb:

    Naja ob das was anderes ist, ist mir egal, ich find Exceptions scheiße und Java auch. :!:

    Wie passt das zu einer C-Funktion mit einem Rückgabewert ohne Exceptions? ;)
    «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