Initialisierung einer Klasse bei Fehler abbrechen.

[lynadge]

Hallo Leute.

Sitze gerade vor einem kleinen Problem.

Ich bastel gerade an einer Klasse für die es notwendig ist, das ein bestimmter Ordner beschreibbar ist. Sollte das nicht der Fall sein, hätte ich
gerne dass das Skript abbricht und die Klasse nicht Initialisiert wird. Da dieser Ordner in so gut wie jeder Methode benutzt wird, macht es wenig Sinn nicht abzubrechen und die Klasse zu Initialisieren.

Ich prüfe in der Methode '__init__()' ob der Ordner beschreibbar ist oder nicht. Genau dort hätte ich auch gerne, das die Initialisierung abbricht und ein Fehler ausgegeben wird.

Mein erster Gedanke war eine Eigenschaft zu setzen die sagt ob der Ordner beschreibbar ist oder nicht, was wiederum in jeder Methode überprüft und mit entsprechender Meldung zurückgegeben wird. Was aber am ende doch recht umständlich ist, wie ich denke.

Mein Ziel ist es eine kleine MiniDateiDatenbank zu schreiben. Wobei der Ordner die Sammelstelle der Datenbanken und jede .bin Datei eine Art Tabelle ist, die mit Pickle gelesen und geschrieben werden.

Habe ich genug Infos gegeben? Vielleicht hat ja jemand von euch eine Idee wie ich das oben genannte Problem lösen könnte.

Gruß, DS

[/me]

Ich bastel gerade an einer Klasse für die es notwendig ist, das ein bestimmter Ordner beschreibbar ist. Sollte das nicht der Fall sein, hätte ich
gerne dass das Skript abbricht und die Klasse nicht Initialisiert wird. Da dieser Ordner in so gut wie jeder Methode benutzt wird, macht es wenig Sinn nicht abzubrechen und die Klasse zu Initialisieren.

Ich prüfe in der Methode '__init__()' ob der Ordner beschreibbar ist oder nicht. Genau dort hätte ich auch gerne, das die Initialisierung abbricht und ein Fehler ausgegeben wird.

Was passiert denn, wenn zwischen dem Überprüfen in __init__ und dem eigentlichen Öffnen der Datei die Schreibrechte auf den Ordner entzogen werden? Du wirst eine Exception bekommen die du irgendwo abfangen kannst.

Und genau das ist meiner Meinung nach die korrekte Methode um damit umzugehen. Wenn du trotzdem gerne vorher von Hand überprüfen möchtest ob ein Schreiben möglich ist dann tu das und wirf manuell eine Exception.

[snafu]

Ein explizites Überprüfen der Dateirechte bei der Initialisierung der Klasse finde ich in Ordnung. Du solltest anschließend aber IMHO nicht mehr dazwischenfummeln. Wenn Python merkt, dass die Datei nicht beschreibbar ist, wird ja eh schon eine Ausnahme geworfen, so dass ein zusätzliches Prüfen von dir redundant wäre. Du kannst aber durchaus eine ``self._write()``-Methode implementieren, die einen ``.write()``-Aufruf auf das Dateiobjekt wrappt und das ganze in einen ``try ... except IOError``-Block packt. Den würden die Methoden dann benutzen.

[lynadge]

Danke für die Denkanstöße.

Ich werde es nun so machen, das ich die Überprüfung in eine separate Methode packe, diese kann der Benutzer dann bei Bedarf aufrufen und mit dem Rückgabewert umgehen wie er möchte.

Da ich nur eine get und eine set Methode habe, hält es sich mit der Redundanz auch in grenzen. Mir war irgendwie so als wenn ich in jeder Methode ein 'open()' benutze. Sollte mal eine Pause machen.

Danke noch mal.

[snafu]

Das mit dem Rückgabewert würde ich nicht machen. Du arbeitest damit gegen das Konzept von Exceptions, wenn du damit anfängst, deine Funktionen/Methoden sowas wie ``-1`` oder ``False`` im Fehlerfall zurückgeben zu lassen. Du hättest ja dann zwangsläufig wieder die Notwendigkeit drin, den Rückgabewert zu überprüfen. Da beisst sich die Katze in den Schwanz.

Wie gesagt: Implementiere einfach dein eigenes ``open_file()`` (oder wie auch immer), dessen Aufgabe lediglich darin besteht, den dahinterliegenden Aufruf zu verdecken und eine besondere Fehlerbehandlung zu haben. Wahlweise könnte noch etwas wie ``error_text`` als Argument angenommen werden, falls die aufrufende Funtion eine spezifische Fehlermeldung haben möchte.

[lunar]

@snafu: Der OP hat doch gar nichts gesagt von wegen Ausnahmen verschlucken. Er möchte doch einfach nur eine zusätzliche Methode anbieten, mit der man bei Bedarf explizit prüfen kann, ob die Datei beschreibar ist. Beim Versuch des Beschreibens wird dennoch eine Ausnahme geworfen, wenn die Datei tatsächlich nicht beschreibbar ist.

Das ist per se nicht verwerflich.

[EyDu]

Durch eine zusätzliche vorherige Prüfung ist allerdings nichts gewonnen, außer eine zusätzliche mögliche Fehlerquelle, komplexeren Code und mehr Arbeitsaufwand. Daher sehe ich auch keinen Sinn darin etwas zu prüfen, auf das man sich nicht verlassen kann.

[snafu]

Klar kann man eine ``is_writable(filename)``-Funktion bauen und benutzen. Manchmal möchte man so etwas ja auch wissen, ohne dass man direkt im Anschluss daran in die Datei schreibt. Wenn es aber in Kombination genutzt wird, empfiehlt es sich trotzdem, das Ganze "atomar" zu gestalten. In dem Moment zwischen Prüfung und tatsächlichem Beschreiben kann sich der Zustand theoretisch immer noch ändern, so dass ordentlich durchdachter Quelltext die mögliche Ausnahme IMHO auch nach der Prüfung behandeln *muss*. Exakt für diese Fälle empfiehlt sich der Wrapper, andernfalls natürlich nicht. Funktionen sollten bekanntlich keine weitreichenderen Aufgaben erfüllen als unbedingt nötig.

[lunar]

@EyDu: Wer sagt denn, dass er das unmittelbar vor dem Beschreiben prüfen möchte? Es spricht doch nur davon, nach Bedarf zu prüfen. Natürlich ist es falsch, unmittelbar vor dem Schreiben explizit zu prüfen, das hat snafu ja detailliert erläutert. Es gibt aber andere Situationen, in denen es durchaus legitim ist, explizit zu prüfen. Man stelle sich einen Datei-Speichern-Dialog vor, der den Benutzer passiv warnt, dass die aktuell gewählte Zieldatei nicht beschreibar ist, damit der Benutzer das Ziel vorneweg korrigieren kann, und nicht erst nach der Fehlermeldung die ganze Speichern-Prozedur neu durchlaufen muss.

[lynadge]

@lunar, genau, ich habe nun nur eine separate Methode die auf Beschreibbarkeit prüft.

Beim eigentlichen Vorgang des Lesens und Schreibens in der Klasse Arbeite ich mit try:except und reiche den Fehler zum Benutzer weiter.

Die zusätzliche Prüfung erspart es aber dem Benutzer der Klasse sich mit der Struktur der gespeicherten Daten auseinanderzusetzen und das spart Ihm Zeit und Code.

//Edit:
Für mich ist es auch wichtig mit z.b. True/False zu arbeiten, da ich dann eine 'If'' Abfrage machen könnte wo nur der Code ausgeführt werden soll der für True/False bestimmt ist, um so dann das Programm/Skript abzubrechen oder angepasst weiter laufen zu lassen. Ein Normaler Benutzer sieht doch nicht gerne Fehlermeldungen direkt aus dem Programmcode, die würde ich dann ggf. Loggen.

[EyDu]

Ich bin von einer unmittelbar vorausgehenden Prüfung ausgegangen und darauf bezog sich auch meine Aussage. Wenn die Aktion nicht unmittelbar nach dem Test erfolgt, dann würde ich die Überprüfung als eigenständiges "Feature" ansehen. Der von dir bereits angesprochene Datei-Dialog wäre auch mein Beispiel für den Unterschied gewesen: Die Überprüfungen der Navigation sollten explizit über den Aufruf der entsprechenden Methoden durchgeführt werden, die eigentliche Schreiboperation hingegen nutzt Ausnahmen.

[snafu]

Schön, dann sind wir uns ja jetzt alle einig.

[lynadge]

Jut.

Wenn ich mit der Klasse fertig bin und alles geplante implementiert habe, stelle ich sie hier mal rein und Ihr könnt über meinen Stil schimpfen.