Format für mehrere Ergebnisse einer Funktion...

[jens]

Ich hab eine Funktion, die mehr als True/False zurück geben kann/soll...

Ich mache mir gerade gedanken über das Format, wie ich die Information zurück geben und Auswerten soll...

Meine Variante:

Code: Alles auswählen

def beispiel():
    if...
        return True
    elif...
        return "Fehler, weil blabla"
    elif...
        return "Fehler, weil was anderes"
    else
        return "Fehler, weil ich weiß auch nicht"

Also bei True ist alles in Ordnung, Ansonten der Fehler-Text...
Oder sollte ich vielleicht PythonLike mit raise "FehlerTexte" arbeiten???

Sonstige Anregungen?

[Leonidas]

Ich würde raise nehmen, aber nicht Texte raisen, sondern Python Objekte die von Exception geerbt haben.

[jens]

Kannst du mal ein kleines Beispiel geben...

Das mit dem Text hat vor und nachteile... Ich kann einfach sagen

Code: Alles auswählen

if result!=True: print "Fehler:", result

Aber wenn ich genauer abfragen will, welcher Fehler es denn nun war, muß ich den String genau abfragen, was ziemlich doof ist...

[Dookie]

Hi jens,

ich würd mir auch die Exceptions und das Handling mal genauer anschauen. http://www.python.org/doc/2.4/tut/node10.html

Code: Alles auswählen

class EigenerError(Exception):
    def __init__(self, msg):
        self.msg = msg
    
    def __repr__(self)
        return repr(self.msg)


def beispiel():
    if...
        return True
    elif...
        raise TypeError("Fehler, weil blabla")
    elif...
        raise ValueError("Fehler, weil was anderes")
    else
        raise EigenerError("Fehler, weil ich weiß auch nicht")

try:
    result = beispiel()
except EigenerError, e:
    print "Achtung '%s' ist aufgetreten!" % e.msg

Gruß

Dookie

[BlackJack]

Soviel muss man doch gar nicht schreiben. Einfach von Exception erben und als Klassenrumpf ein simples 'pass' sollte genügen.

Code: Alles auswählen

>>> class MyError(Exception): pass
...
>>> e = MyError("Blah")
>>> print e
Blah

[Leonidas]

Davon abgesehen sind String Exceptions nicht mehr gerne gesehen, da sie recht unflexibel sind.

[jens]

Aha! Danke euch allen damit komme ich mehr Pythonlike weiter

[CM]

Davon abgesehen sind String Exceptions nicht mehr gerne gesehen, da sie recht unflexibel sind.

Wie? Wann? Was? Wo? Warum?
Eigentlich mache ich es ständig im wesentlichen so wie von Dookie vorgeschlagen. Bei etwas komplexeren Programmen fange ich sogar manchmal best. Fehler ab und gebe eigene Exceptions aus - weil ich potentielle Fehler des Nutzers kenne und so eine detaillierte Auskunft geben kann, was falsch läuft. (Natürlich muß man beim Abfangen von Pythonexceptions Vorsicht walten lassen.)
Gebe zu, daß Dookies Beispiel nur einem Gerüst entspricht: Wenn man nur so wenig machen will, mag BlackJacks Alternative reichen. Aber sonst? Gibt es irgendwo geänderte Richtlinien? - Ich habe bislang nichts dergleichen gesehen. Wäre nett, wenn ihr einen Hinweis geben könntet.

Gruß,
Christian

[Leonidas]

Wie? Wann? Was? Wo? Warum?
Eigentlich mache ich es ständig im wesentlichen so wie von Dookie vorgeschlagen.

Ja, Dookie wirft aber auch keine String Exceptions.

Aber sonst? Gibt es irgendwo geänderte Richtlinien? - Ich habe bislang nichts dergleichen gesehen. Wäre nett, wenn ihr einen Hinweis geben könntet.

Ich glaube du hast nicht verstanden was ich mit String Exceptions meine, die sind wirklich deprecated.

Folgendes geht, ist aber eben nicht gerne gesehen:

Code: Alles auswählen

raise "Der Blabla Fehler"

Jens wollte sowas machen, darauf habe ich gesagt, dass es deprecated ist. Ist ja auch schon älter als das Exception Objekt und war wohl die ursprüngliche Form Exceptions zu werfen.

[CM]

Hast Recht: Ich habe nicht begriffen, daß Du den Jens meintest. Und mit der zweiten Vermutung hast Du auch Recht: Ich kannte String Exceptions im engeren Sinne nicht. War wohl vor meiner Python-zeit.
Tut mir leid.

Gruß,
Christian