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:

    Übrigens neigt Java-Code dazu, so viele Exceptions zu fangen, dass es am Ende eine try-Wüste wird.

    Das ist meines Erachtens eher eine Frage des (schlechten) Programmierstils. Ich behandle Ausnahmen möglichst immer so spät wie möglich. Vielleicht haben viele Java-Anfänger einfach auch nur Angst davor, wenn sie eine Exception nicht behandeln. Das führt dann meistens zu einer Fehlerverschluckung anstatt -behandlung. ;)

    Amin Negm-Awad schrieb:

    Was ist eigentlich, wenn du es vergisst, eine Exception zu werfen?

    Das ist wie ein Finanzminister, der das Haushaltsloch verschweigt. ;)
    „Meine Komplikation hatte eine Komplikation.“

  • Ja, man muss sie nur richtig behandeln. Vor allem, wenn nach einer Exception (implizit) Objekte dekonstruiert und die Dekonstruktion … eine Exception werfen kann. Holdrio, mit Exceptions wird alles so klar und einfach.
    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"?

  • Das ist meines Erachtens eher eine Frage des (schlechten) Programmierstils. Ich behandle Ausnahmen möglichst immer so spät wie möglich. Vielleicht haben viele Java-Anfänger einfach auch nur Angst davor, wenn sie eine Exception nicht behandeln. Das führt dann meistens zu einer Fehlerverschluckung anstatt -behandlung. ;)


    Das ist nicht immer eine Frage des Stils. Manchmal kann man sich nicht dagegen wehren. Nämlich dann, wenn ein Framework wie zum Beispiel JDBC zum Einsatz kommt:

    1. Das Ausführen eines Queries kann eine Checked-Exception werfen.
    2. Im Exceptionhandler will man dann eigentlich die Datenbankverbindung schließen um keine Resourcen zu leaken.
    3. Die close()-Methode kann aber ihrerseits wieder eine Checked-Exceptions werfen.

    Das endet dann in einer try catch try catch-Wüste, die Amin ansprach.

    Natürlich kann man auch einfach ein anderes Framework nutzen und bei eigenem Code ist es sicherlich eine Frage des Stils. Nicht ohne Grund werden auch mittlerweile in Java mehr Runtime-Exceptions benutzt, die man nicht explizit behandeln muss.
    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].

  • Amin Negm-Awad schrieb:

    Ja, man muss sie nur richtig behandeln. Vor allem, wenn nach einer Exception (implizit) Objekte dekonstruiert und die Dekonstruktion … eine Exception werfen kann. Holdrio, mit Exceptions wird alles so klar und einfach.

    Ah ok, den Fall meintest Du. Das handhabe ich meistens über ein Try-Finally (ohne Catch) und die Ausnahme für das close() fliegt gleichberechtigt mit den anderen Ausnahmen des try-Blocks zu dem Aufrufer zurück.

    Um Missverständnisse zu vermeiden: Ich plädiere ganz gewiss nicht für den Einsatz von Ausnahmen in Objective-C. Ich finde sie dort manchmal auch eher störend. In Java sind sie halt nun mal inhärent und man muss das Beste daraus machen ;)
    „Meine Komplikation hatte eine Komplikation.“

  • 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.

    Exceptions sind auf dem Papier bequem. (Sie sind nie notwendig.) Sobald man das allerdings beliebig kombiniert, wird es exponentiell kompliziert.

    Und nein, ich würde dir auch nicht unterstellen wollen, für Exceptions Werbung zu machen. :-]

    +++

    Um das klar zu machen: Christian und ich sprechen nicht von demselben Fall. Bei mir ist es einfach ein Destructor, der die Exception wirft. Denke etwa an RAII. Da dies auch Dekonstruktion ist Resourcenfreigabe bedeutet, kann dir da im Prinzip alles um die Ohren fliegen.
    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"?

  • Ich persönlich finde ja, dass Java und C# die Exceptions inflationär behandeln. Also so ohne drüber nachzudenken.

    Beispiel: Ich möchte einen Stream schließen.

    Annahme: Der Stream ist offen.

    Logische Schlussfolgerung: Wenn der Stream offen ist, schließe ihn.
    Wenn der Stream nicht offen ist, scher dich nicht weiter drum.

    Tatsächliche Implementierung: Wenn der Stream offen ist, schließe ihn.
    Wenn der Stream nicht offen ist, wirf eine IOException. +ähm+
    «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

  • Genau da liegt das Problem. Wenn man sich etwa RAII auf wiki anschaut:
    de.wikipedia.org/wiki/Ressourc…_Initialisierung#Beispiel

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

    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.

    Man mag mir erklären, warum das einfacher ist oder weniger "Vergesslichkeitsprobleme" verursacht, als anständige Ifs.
    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"?

  • macmoonshine schrieb:

    Marco Feltmann schrieb:

    Tatsächliche Implementierung: Wenn der Stream offen ist, schließe ihn.
    Wenn der Stream nicht offen ist, wirf eine IOException. +ähm+

    Das ist nicht richtig; zumindest nicht allgemeingültig. Z. B. einen geschlossenen FileInputStream kannst Du auch ohne IOException schließen.

    Gemäß Doku wirft es (zumindest in der Implementierung für Android) eine IOException.
    Wie auch immer das zu 'this implementation does nothing' passen mag, doch was in der Doku steht ist für mich Gesetz.

    (Vermutlich ist es Implementierungsdetail, ob die Klasse noch irgendwas mit dem Stream vor dem Schließen tut. Allerdings wäre dann die Bezeichnung 'close' irreführend.)
    «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

  • macmoonshine schrieb:

    Marco Feltmann schrieb:

    Tatsächliche Implementierung: Wenn der Stream offen ist, schließe ihn.
    Wenn der Stream nicht offen ist, wirf eine IOException. +ähm+

    Das ist nicht richtig; zumindest nicht allgemeingültig. Z. B. einen geschlossenen FileInputStream kannst Du auch ohne IOException schließen.

    Ist ja gleichgültig, wie das im Einzelfall ist. Jedenfalls existieren Methoden, die bei einer "Aufgabe" wieder eine Exception werfen können, was zu der Frage führt, wie komplex das Ganze wird, wenn die Aufgabe Teil einer Exceptionbehandlung ist. Christian hatte dazu ja ein Beispiel genannt.
    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:

    Denke etwa an RAII.

    An so etwas möchte ich gar nicht denken, auch wenn ich es manchmal muss ;)

    Amin Negm-Awad schrieb:

    Da dies auch Dekonstruktion ist Resourcenfreigabe bedeutet, kann dir da im Prinzip alles um die Ohren fliegen.

    Genau aus solchen Gründen. :D

    In Java hast Du ja keinen echten Destruktor, und dieses Surrogat finalize() benutzt man ja nicht wirklich.
    „Meine Komplikation hatte eine Komplikation.“

  • Das ist wie ein Finanzminister, der das Haushaltsloch verschweigt.


    Dann wäre ja Exceptions vergessen völlig normal, Standardpattern. Schlechter Vergleich ;)

    oder bin ich etwa wieder der Einzige der das nicht so macht ;)


    Denke die Frage wäre mal geklärt ;)

    Also ich hab jetzt nicht vor, in Zukunft diesen Weg zu gehen. Es kam eben in dem Kurs die Frage auf, ob man das nicht mit @try ... machen könnte. Dann hab ich erst mal ein "Häääää Gesicht" gemacht.

    Aus meiner Sicht, sind Exceptions eben kein "Standardweg" um den Programmablauf zu steuern, sondern ein klarer Hinweis darauf, das man sich gerade in irgendeinem Undefinierten Zustand befindet. Die sind nicht zum Abfangen, sondern zum vermeiden da.

    Aber in Java werden die wohl öfters verwendet. Ist ja auch ne andere Welt. Jedenfalls verstehe ich jetzt, warum die Java Leute in den Kursen immer so wild auf Exceptions sind.
    Seminare, Artikel, Code. ObjectiveCeeds - alles für die Apfelzucht.

  • Das gehört dann zu meinem Ratschlag, dass man erst einmal ne Flasche Wodka litern sollte, wenn man von einer anderen Sprache auf Objective-C wechselt. Vor dem Bau eines neuen Gebäudes gehört ein altes abgerissen.

    Gerne diskutieren die dann ja auch, was besser ist. Ich gebe die Diskussion mittlerweile schnell auf:

    IN! OBJECTIVE_C! MACHT! MAN! DAS! NICHT! SO! UND! WENN! SIE! ES! SO! MACHEN!, DANN! PROGRAMMIEREN! SIE! NICHT! IN! OBJECTIVE-C!, SONDERN! IN! $programmiersprache MIT! OBEJCTIVE-C!-SYNTAX! DAS! GEHT! IN! DIE! HOSE!
    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"?

  • Manfred Kreß schrieb:

    Das ist wie ein Finanzminister, der das Haushaltsloch verschweigt.


    Dann wäre ja Exceptions vergessen völlig normal, Standardpattern. Schlechter Vergleich ;)

    Nö, guter Vergleich! Wie oft sitzt man vor irgendeinem #*%$@&?+; Programm, was irgendeine #*%$@&?+; Operation nicht ausführt. Man kann aber nix dran machen, weil einem dieses #*%$@&?+; Programm nicht sagt, was los ist. :D
    „Meine Komplikation hatte eine Komplikation.“

  • Das erinnert mich daran, dass ich noch einen Vortrag für die Cocoaheads Hamburg zum Thema Exception Handling vs. Error Handling basteln wollte...
    «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

  • Ihr diskutiert hier nicht ernsthaft darüber, ob Exceptions oder Error-Objekte besser sind, oder? Beides manchmal praktisch, beides manchmal extrem nervig. In beiden Fällen sollte man wissen, was man tut, ist immer so.

    Mein Senf zur Ursprungsfrage: Macht man nicht. Aber aus einem ganz anderen Grund: Ist nicht lesbar. Jeder Objective-C-Programmierer denkt "Exception = Programmierfehler". Abweichen von der Konvention macht Code per se unverständlicher, dafür braucht man schon einen extrem guten Grund, und den gibt's hier nicht. Hier kann man doch einfach einen NSError in einer if-Kette mitschleifen. Sieht etwas umständlich aus, ist es aber gar nicht. Und gut lesbar.

    In Java ist das halt eine andere Sache, da sind Exceptions ganz normal. Das ist aber zu 1% technisch begründet und zu 99% Konvention.
    Multigrad - 360°-Produktfotografie für den Mac

  • Übrigens zu meinem obigen Beispiel: Ich habe in Objective-Cloud tatsächlich einen Fall, in der das Versenden eines Fehlers, einen Fehler verursachen kann. Ich handhabe das so, dass ich mir denke: "Ah, so ist das also, so, so, dann sag ich besser gar nichts mehr." Ich hätte natürlich auch noch versuchen können, "si tacuisse" über die Leitung zu jagen.
    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"?

  • Ich weiß gar nicht worüber man da diskutieren muss. Exception sagt doch schon das Wort ist die Ausnahme. Wenn man anfängt diese regelmäßig zu benutzen führt man den eigentlichen Verwendungszweck ad absurdum.

    Dabei ist total wurscht ob ich damit ein paar Codezeilen sparen kann oder nicht.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)

  • Thallius schrieb:

    Exception sagt doch schon das Wort ist die Ausnahme. Wenn man anfängt diese regelmäßig zu benutzen führt man den eigentlichen Verwendungszweck ad absurdum.

    Das sehe ich sowas von genauso. Nur eingefleischte Java-Entwickler sehen das völlig anders.

    Für die ist FileNotFound ein schwerer Ausnahmefehler – wenn ich von einer frisch gekauften und meinem System entsprechend formatierten Festplatte ausgehe, ist FileNotFound eher die Regel. ;)
    Klar, das Wegbrechen eines FileInputStream oder FileOutputStream (Date wird während der Bearbeitung gelöscht) ist ein schwerer Ausnahmefehler.
    Die bloße Nichtexistenz der Datei 'dateiInDieIchUnbedingtAllesMöglichePackenMussMitUnmöglicherDateiend.ung' jedoch nicht.
    «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