Ergebnis 1 bis 20 von 34

Thema: Exceptions

Hybrid-Darstellung

Vorheriger Beitrag Vorheriger Beitrag   Nächster Beitrag Nächster Beitrag
  1. #1
    Also sowas wie

    Code (C++):
     
    void MeStupid() {
        try {
            if (SomeFunc() == false) {
                throw SomeFuncFailed();
            }
        } catch (const SomeFuncFailed& e) {
            GoNuts();
        }
    }
     


    ?

  2. #2
    Zitat Zitat von Kyuu Beitrag anzeigen
    Wenn ich nochmal auf diesen Artikel verweisen darf und das Problem dort mit Int32.Parse(). Das ist zwar C#-bezogen, aber die Problematik dort ist sprach-/frameworkunabhängig, nämlich: Exceptions sollten nicht für die Flusskontrolle verwendet werden. Solltest du auf so etwas stoßen, darfst du es als Designfehler abstempeln und die API-Designer darin kritisieren, dass es ein Boolean-Rückgabewert auch getan hätte und das viel eleganter.
    Naja, ein Boolean-Rückgabewert geht da eben kaum, weil die Methode bereits ein Integer zurückgeben soll. Dass es keine einfache Möglichkeit gibt/gab (in Java ja bis heute genauso), vorher die Gültigkeit zu überprüfen (am besten auch noch, ohne dadurch die gleiche Arbeit zweimal zu erledigen, irgendwie will man ja doch noch Performance im Auge behalten) ist natürlich ungünstig, aber ich wüsste nicht wirklich, was die Methode bei einem ungültigen String machen sollte, außer eine Exception zu werfen. Und eine gute Möglichkeit, vorher die Gültigkeit zu testen, fällt mir auch spontan nicht ein, wenn man nicht für jedes Parsing ein eigenes Parser-Objekt erzeugen will.
    (Disclaimer: All das bezieht sich auf Javas Integer.parseInt(), mit der implziten Annahme, dass das in C# praktisch genauso ausschauen wird.)
    Zitat Zitat
    @affe (wenn ich dich so nennen darf ^^):

    Der klassische C-Ansatz ist doch eher, dass der Rückgabewert entweder in einem gültigen oder in einem ungültigen Wertebereich liegt, worauf man prüft, und der Fehlercode in einer globalen, "errno"-ähnlichen Variable gespeichert wird. Natürlich muss man immernoch den Fehlercode interpretieren, aber das kann man generalisiert erledigen.
    Ja, meinte ich ja, halt irgendeinen speziellen Rückgabewert zurückliefern, ungeachtet dessen ob der jetzt direkt den konkreten Fehler angibt oder auch noch eine globale Variable (= inhärentes x__X) benötigt. Jedenfalls muss man jeden Aufruf in ein if hüllen – oder alle Rückgabewerte sammeln (bei nicht aufeinander aufbauenden Aufrufen) und dann eine Riesen-if-Party am Ende veranstalten. *kratz*

    Und: Ja, darfst du. XD

    Zitat Zitat von Kyuu Beitrag anzeigen
    Also sowas wie
    […]
    ?
    Habe ich auch schon gesehen, und in manchen komplizierteren Fällen ergibt's sogar Sinn. Als bloßen Workaround für GOTOs aber natürlich absolut grauslich. x__X

  3. #3
    Zitat Zitat von drunken monkey Beitrag anzeigen
    Naja, ein Boolean-Rückgabewert geht da eben kaum, weil die Methode bereits ein Integer zurückgeben soll. Dass es keine einfache Möglichkeit gibt/gab (in Java ja bis heute genauso), vorher die Gültigkeit zu überprüfen (am besten auch noch, ohne dadurch die gleiche Arbeit zweimal zu erledigen, irgendwie will man ja doch noch Performance im Auge behalten) ist natürlich ungünstig, aber ich wüsste nicht wirklich, was die Methode bei einem ungültigen String machen sollte, außer eine Exception zu werfen. Und eine gute Möglichkeit, vorher die Gültigkeit zu testen, fällt mir auch spontan nicht ein, wenn man nicht für jedes Parsing ein eigenes Parser-Objekt erzeugen will.
    (Disclaimer: All das bezieht sich auf Javas Integer.parseInt(), mit der implziten Annahme, dass das in C# praktisch genauso ausschauen wird.)
    Man kann auch out-Parameter benutzen:
    Code (C++):
     
    class Int32 {
    public:
        // ...
        bool Parse(const string& s, int32& out) {
            // ...
        }
        // ...
    };
     

    Und diese sind alles andere als unüblich.

    Zitat Zitat von drunken monkey Beitrag anzeigen
    Habe ich auch schon gesehen, und in manchen komplizierteren Fällen ergibt's sogar Sinn. Als bloßen Workaround für GOTOs aber natürlich absolut grauslich. x__X
    Wenn man die Exception nicht fängt und nach außen propagieren lässt - und nur dann - wäre es sinnvoll, imo. Eleganter wäre es sowieso, wenn SomeFunc() selbst wirft, aber selbstverständlich kann es sein, dass diese zu irgendeiner externen Bibliothek gehört, die aus irgendeinem Grund keine Exceptions nach außen lässt, oder sie überhaupt nicht verwendet.

  4. #4
    Zitat Zitat von Kyuu Beitrag anzeigen
    Man kann auch out-Parameter benutzen:
    Ah, OK, deswegen eben mein Disclaimer. In Java gibt's die ja nicht.
    In C# wäre das dann wohl wirklich die deutlich bessere Lösung.

  5. #5
    Zitat Zitat von Kyuu Beitrag anzeigen
    Also sowas wie

    Code (C++):
     
    void MeStupid() {
        try {
            if (SomeFunc() == false) {
                throw SomeFuncFailed();
            }
        } catch (const SomeFuncFailed& e) {
            GoNuts();
        }
    }
     


    ?
    exakt so. Aber gut das ich hier was gelernt hab, jetzt kann ich das bei der Semesterausgabe anwenden.

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •