Trotz Rückgabetyp nichts zurückgeben?



  • Also ich glaube, für sowas würde ich exceptions (= ausnahmen) verwenden.
    Sonst musst du dich halt mit Pointern oder anderen Sachen begnügen.


  • Mod

    Black'Tea schrieb:

    Hallo,
    ich habe ein kleines Problem und zwar würde ich gerne in einer Funktion, trotz rückgabetyp, nur bei bestimmten erfüllten bedingungen etwas zurückgeben lassen mit return. Wie gebe ich, wenn diese Bedingungen nicht erfüllt sind, einfach nichts zurück?

    "einfach nichts zurückgeben" ist nicht möglich - Wie soll sich der Aufrufer sonst auf irgendetwas verlassen? Du kannst eine Exception werfen, das ist aber vermutlich nicht das Gewünschte. Oder du reservierst dir einen bestimmten Wert des Rückgabetyps (oder erweiterst den Rückgabetyp entsprechend), so dass dieser 'nichts' repräsentiert.



  • In ganz bestimmten Situationen, die Funktion nicht vollständig korrekt ausführen, riecht eindeutig nach einer Ausnahme (exceptions).
    http://www.kharchi.de/cppratgeber3.htm



  • danke für die schnellen guten antworten. Habe mich für den Zeiger entschieden.



  • Es kann auch sowas manchmal Sinn machen - kommt auf die genaue Anwendung an:

    bool Foo(int& outBar)
    {
        if (...)
        {
            outBar = ...;
            return true;
        }
        else
            return false;
    }
    


  • ich würde als rückgabetyp einfach ein leeres objekt werfen, oder einfach ein -1 oder 0 oder dergleichen bei int und dies dann abfragen

    problem bei der objekt-rückgabe ist nur, dass es manchmal keinen standard-konstruktor gibt und somit kein "leeres" objekt erzeugt werden kann.



  • Black'Tea schrieb:

    nur bei bestimmten erfüllten bedingungen

    das schreit förmlich nach exception.
    wenn es sinn macht, in dem fall einen "neutralen" wert zurückzuliefern, kann man auf die exception verzichten. ein beispiel wäre z.b. eine methode, die die position eines chars in einem string sucht. die kann bei nicht-vorhandensein des strings einfach einen wert kleiner 0 liefern. aber wenns darum geht, dass die methode mit parametern aufgerufen wurde, die dazu führen, dass die methode keinen sinnvollen wert liefern kann, dann sollte sie eine exception schmeissen.
    der grund ist der, dass die übergabe von "schlechten" parametern auf einen programmierfehler hinweist.



  • bei Flieskommatypen gibt es ein NaN Wert, der immer bei aktionen, wie dei Division durch null entsteht, den kann man auch verwenden.



  • Krux schrieb:

    bei Flieskommatypen gibt es ein NaN Wert, der immer bei aktionen, wie dei Division durch null entsteht, den kann man auch verwenden.

    ja, den wert gibt es in vielen sprachen. und leider kann man in den meisten sprachen mit diesem wert sogar weiterrechnen (bleibt halt immer NaN), bis irgendwann mal tatsächlich ein konkreter wert benötigt wird, um z.b. die breite eines fensters zu setzen und dann platzt die anwendung.
    eine division durch 0 ist hochgradig undefiniert und sollte *immer* eine exception schmeissen.



  • Hm. NaNs sind ein interessantes Thema und IMO "potentiell gefährlich", gerade weil die Erzeugung von NaNs und auch das Handling z.T. unterschiedlich gehandhabt werden. Siehe z.B.: http://en.wikipedia.org/wiki/NaN

    Von daher würde ich grundsätzlich eher davon abraten NaNs zu verwenden.



  • Division durch 0 erzeugt normalerweise nur +Inf oder -Inf. 0/0 ergibt NaN.



  • Denkt dran, dass Ausnahmen nur Sinn machen wenn es überhaupt möglich sein könnte darauf zu reagieren. Eine Division durch 0 ist so gut wie immer ein Bug und keine außergewöhnliche Situation. Da ich noch keine Programm gesehen habe das selbständig während der Ausführung Bugs gefixt hat behaupte ich, dass man besser hat bei einer Division durch NULL das Programm abzubrechen als eine Ausnahme zu werfen.



  • Ben04 schrieb:

    Denkt dran, dass Ausnahmen nur Sinn machen wenn es überhaupt möglich sein könnte darauf zu reagieren. Eine Division durch 0 ist so gut wie immer ein Bug und keine außergewöhnliche Situation. Da ich noch keine Programm gesehen habe das selbständig während der Ausführung Bugs gefixt hat behaupte ich, dass man besser hat bei einer Division durch NULL das Programm abzubrechen als eine Ausnahme zu werfen.

    ACK 👍 🙂


  • Mod

    Ben04 schrieb:

    Eine Division durch 0 ist so gut wie immer ein Bug und keine außergewöhnliche Situation.

    Auf eine Division durch 0 kann sowieso nicht mit einer Exception reagiert werden...



  • Also ich hab durchaus Anwendungssituationen gehabt, wo eine Division durch Null auch logisch Sinn ergeben würde, allerdings fange ich das bereits vorher ab.

    Naiv wäre zB ein x / min(1, ...)

    Von daher würde ich die Null-Exception nicht grundsätzlich ausführen.



  • camper schrieb:

    Ben04 schrieb:

    Eine Division durch 0 ist so gut wie immer ein Bug und keine außergewöhnliche Situation.

    Auf eine Division durch 0 kann sowieso nicht mit einer Exception reagiert werden...

    Wenn die Implementierung das ermöglich schon.
    Mit MSVC geht sowas.
    Eine Division durch 0 erzeugt eine Win32 structured exception, und diese kann man wiederum mit hilfe einer "translator funktion" in eine C++ Exception verwandeln.

    Standard ist es natürlich nicht, aber auch kein "Hack", sondern ein Feature der Implementierung.


  • Mod

    hustbaer schrieb:

    camper schrieb:

    Ben04 schrieb:

    Eine Division durch 0 ist so gut wie immer ein Bug und keine außergewöhnliche Situation.

    Auf eine Division durch 0 kann sowieso nicht mit einer Exception reagiert werden...

    Wenn die Implementierung das ermöglich schon.
    Mit MSVC geht sowas.
    Eine Division durch 0 erzeugt eine Win32 structured exception, und diese kann man wiederum mit hilfe einer "translator funktion" in eine C++ Exception verwandeln.

    Standard ist es natürlich nicht, aber auch kein "Hack", sondern ein Feature der Implementierung.

    Du bist jetzt für die Beantwortung der nächsten 10 newbie-Fragen zum Thema __try/__except in diesem Forum (wo sie nichts verloren haben) zuständig. 😉


Anmelden zum Antworten