Guten Tag,
kurze Frage:
kann ich Python in einen Modus 'schalten' der das Abfangen von Exceptions erzwingt?
Soweit ich verstehe kann ich eine Exception abfangen, muss das aber nicht. Fange ich sie nicht wird die Exception so lange nach oben weiter gereicht bis das Programm abbricht.
Mir würde ein Verhalten wie in Java, wo eine 'normale' Exception' irgendwo behandelt werden muss, viel mehr entgegen kommen.
Danke!
Sparrow
Anlegen eines try-blocks erzwingen
- birkenfeld
- Python-Forum Veteran
- Beiträge: 1603
- Registriert: Montag 20. März 2006, 15:29
- Wohnort: Die aufstrebende Universitätsstadt bei München
Kurze Antwort: nein, es gibt keine "checked exceptions". Python kann weder zur Kompilier- noch zur Laufzeit wissen, welche Exceptions ein Aufruf auslösen kann, bis wirklich eine ausgelöst wird.
Eine längere Antwort erfordert, dass du noch ein bisschen mehr über deine eigentlichen Anforderungen erzählst.
Eine längere Antwort erfordert, dass du noch ein bisschen mehr über deine eigentlichen Anforderungen erzählst.
ich glaube das geht nicht. das müsstest du per hand machen oder eben in die oberste zeile schon try: und ganz unten eben except: print ":(" ^^ sorry
/edit: zu langsam..
/edit: zu langsam..
Hallo Sunjy,
hier mal ein Beispiel aus Java, ein simples Programm das genau gar nichts macht ausser ein Objekt der Klasse URL zu instanzieren. Dafür gibt es die Möglichkeit den Namen der URL als String zu übergeben.
Unter Java lässt sich der Code jedoch so nicht übersetzen da eine MalformedURLException abgefangen werden muss. Ich bin als gezwungen zu definieren was passiert falls die entsprechende Exception auftritt. Folgender Code würde sich problemlos übersetzen lassen:
Genau so ein Verhalten würde ich mir auch bei Python wünschen, da ich mir gut vorstellen kann bei größeren Projekten gerne mal einen try-Block zu vergessen. Mir wäre es lieber die Umgebung würde darauf bestehen, dass Ausnahmen auch behandelt werden.
Gruß
Sparrow
hier mal ein Beispiel aus Java, ein simples Programm das genau gar nichts macht ausser ein Objekt der Klasse URL zu instanzieren. Dafür gibt es die Möglichkeit den Namen der URL als String zu übergeben.
Code: Alles auswählen
import java.net.URL;
public class ExcT {
public static void main(String[] args) {
URL url = new URL("http://www.example.com");
}
}
Code: Alles auswählen
import java.net.MalformedURLException;
import java.net.URL;
public class ExcT {
public static void main(String[] args) {
try {
URL url = new URL("http://www.example.com");
} catch (MalformedURLException e) {
// Catch the Exception here
}
}
}
Gruß
Sparrow
das geht wie gesagt glaube nicht. aus deinem Quelltext oben kann ich nur aufgrund von Erfahrung herauslesen, da ich kein Java kann, abe rich glaube zu wissen was er tut, du hasts ja auch erklärt.
Trotzdem wie gesagt ich glaube, dass du da mit try und except arbeiten musst.
Zumindest weis ICH nicht wie es geht, wenn es überhaupt machbar ist.
Trotzdem wie gesagt ich glaube, dass du da mit try und except arbeiten musst.
Zumindest weis ICH nicht wie es geht, wenn es überhaupt machbar ist.
Nunja, Schwachsinnig ist das nicht.derdon hat geschrieben:Das finde ich ziemlich schwachsinnig. Warum werde ich dazu gezwungen Fehler abzufangen, die *vielleicht* gar nicht auftreten? Ein Fehler soll doch nur dann abgefangen werden, wenn auch einer auftritt.
Du definierst ja das was passiert wenn der Fehler auftritt. Die try-Blöcke jeder mir bekannten Programmiersprache funktionieren so, auch die in Python.
Mit try und except muss ich so oder so arbeiten. Ich will nur in den Popo getreten werden falls ich es nicht tueSunjy hat geschrieben:Trotzdem wie gesagt ich glaube, dass du da mit try und except arbeiten musst.
Schade, dass das in Python nicht funktioniert. Ich denke das liegt daran, dass in Pyhon erst zur Laufzeit kompiliert oder interpretiert wird, bzw. es keinen erzwungenen Compilerschritt gibt der den Quellcode untersucht.
Ich werde mal drüber nachdenken und schauen ob ich nicht ein Tool bastele was einen Python-Quelltext auf unbehandelte Exeptions untersucht.
Trotzdem danke!
Sparrow
Mit so einer Anforderung stellst Du halt das dynamische Konzept teilweise in Frage, welches für viele Leute gerade den Prinz-Charming-Faktor von Skriptsprachen ausmacht. Kompilierende Sprachen sind für sowas (wie auch Typprüfungen) im Vorteil, da das während des Kompilierens schon abgefangen werden kann.
In Python könntest Du sowas durch Decoratoren halbwegs elegant nachbauen, wobei ein zu intensiver Gebrauch hiervon den Code mächtig aufbläst, der zur Laufzeit dann auch gestemmt werden muß.
In Python könntest Du sowas durch Decoratoren halbwegs elegant nachbauen, wobei ein zu intensiver Gebrauch hiervon den Code mächtig aufbläst, der zur Laufzeit dann auch gestemmt werden muß.
Was hast du eigentlich konkret dagegen?
Wenn du eine Exception vergisst, merkst du das spätestens wenn die Exception bis nach oben gereicht wurde und das Programm abstürzen lässt.
Und so schwer ist's auch nicht an den richtigen Stellen solche try-catch Blöcke zu setzen Man sieht doch quasi "Ah, hier könnte was schief laufen" und "Hier tritt sicherlich keine Exception aus (außer vllt nem SyntaxError)".
Und wenn du wirklich mal etwas übersehn hast und das Programm abstürzt ... Wo liegt das Problem? Einfach abändern.
Wenn du eine Exception vergisst, merkst du das spätestens wenn die Exception bis nach oben gereicht wurde und das Programm abstürzen lässt.
Und so schwer ist's auch nicht an den richtigen Stellen solche try-catch Blöcke zu setzen Man sieht doch quasi "Ah, hier könnte was schief laufen" und "Hier tritt sicherlich keine Exception aus (außer vllt nem SyntaxError)".
Und wenn du wirklich mal etwas übersehn hast und das Programm abstürzt ... Wo liegt das Problem? Einfach abändern.
Nein, in der Beziehung verhält sich Python genau wie Java (bis auf die Tatsache, dass ein JIT fehlt). Das liegt daran, dass Python dynamisch typisiert ist, deswegen kann, wie birkenfeld schon schrieb, Python nicht wissen ob eine Exception geworfen werden kann.sparrow hat geschrieben:Schade, dass das in Python nicht funktioniert. Ich denke das liegt daran, dass in Pyhon erst zur Laufzeit kompiliert oder interpretiert wird, bzw. es keinen erzwungenen Compilerschritt gibt der den Quellcode untersucht.
Deswegen ist es auch sehr anspruchsvoll so ein Tool zu schreiben, das dies erledigt. Dazu müsstest du schon konsequent die Typen und Exceptions angeben (z.B. über die Python 3 function annotations oder Kommentare) und das dann auswerten. Und zwar überall, also könntest du weder die Standardbibliothek noch Bibliotheken von Dritten verwenden. In dem Fall wäre es dann wohl wirklich sinnvoller eine andere Sprache zu verwenden.
Mal davon abgesehen, das Python für "checked exceptions" zu dynamisch ist, haben auch viele statisch kompilierte Sprachen mit Ausnahmebehandlung so etwas nicht. "checked exceptions" sind für mich eines der grössten Probleme in Java. Es verhindert zum Beispiel, dass man einfach generischen Code schreiben kann. Zum Beispiel so etwas wie `map()` mit einem "Funktionsobjekt" und einem Iterator, weil man ja nicht weiss, was das Funktionsobjekt alles als Ausnahme werfen kann. Workaround ist bei so etwas dann normalerweise, dass man eine eigene Ausnahme definiert und alles fängt und in diese neue Ausnahme verpackt um es dann weiter zu werfen. Aufrufer müssen dann die Ausnahme fangen und reinschauen, was denn der eigentliche Grund war. Das wird schnell hässlich.
Das ist falsch. Es gibt in Java Runtime-Exceptions (unchecked exceptions) die man nicht fangen muss aber kann, dazu gehört auch die NullPointerException.Darii hat geschrieben:Davon abgesehen, dass es bei Java immer noch Nullpointer-Exceptions gibt, die man nicht abfangen muss. Ist also auch nur eine scheinbare Sicherheit.
Dadurch wird die Sicherheit aber nicht scheinbar, denn eine NullPointerException kann nur auftreten wenn auf Objekt verwiesen und zugegriffen wird das null ist.
Falls das anders sein sollte müsste dann der gesamte Quellcode in einem try/catch-Block stehen, denn als rein objektorientierte Sprache kommt in so ziemlich jeder Zeile eine Objekt vor.
So einfach kannst du es dir daher nicht machen.
Ich bin bereits am schauen wie man möglichst einfach an die benötigten Informationen kommt um prüfen zu lassen welche Exceptions in einem Programm nicht abgefangen werden.
Für die Qualitätsprüfung von Code finde ich das ziemlich wichtig und bei größeren Projekten unerlässlich.
Dynamik hin oder her, zumindest die Möglichkeit der Prüfung sollte es mE geben.
Gruß
Sparrow
Mal abgesehen davon kann man die Exception in Java genau so nach oben weiter reichen (mit dem Schlüsselwort throws), das Abfangen der Exception ist nicht Pflicht!
Code: Alles auswählen
import java.net.MalformedURLException;
import java.net.URL;
public class ExcT {
public static void main(String[] args) throws MalformedURLException {
URL url = new URL("http://www.example.com");
}
}
@sparrow: NPEs kommen nur vor, wenn man versucht auf ``null`` wie auf ein Objekt zuzugreifen. Tja, und `MalformedURLException`\s kommen nur vor, wenn man eine URL übergibt, die keine ist. Und nun?
Code wäre durchaus "sicherer", wenn man weniger an NPEs denken müsste. Die Sprache Nice erlaubt zum Beispiel keine ``null``-Werte, wenn man nicht explizit bei der Deklaration angibt, dass die Variable auch den Wert ``null`` annehmen darf. Denn das braucht man ja eigentlich gar nicht so häufig -- meistens sorgt man ja dafür, dass die Variablen "ordentliche" Werte enthalten.
Java würde ich übrigens nicht als "rein objektorientiert" beschreiben. Dafür gibt es zu viele Sprachelemente, die keine Objekte sind. Primitive Typen und Klassen zum Beispiel. Da ist Python schon "objektorientierter". Aber immer noch nicht so weit wie Io, wo es keine Klassen, sondern nur noch Objekte gibt, und auch die "Aufrufe" Nachrichten sind, die sich die Objekte zuschicken, wobei die Nachrichten natürlich auch wieder Objekte sind.
Dein Ansinnen ist einfach nicht lösbar. Du kannst nicht statisch feststellen welche Ausnahmen zur Laufzeit ausgelöst werden könnten.
Wenn Du die Qualität sichern willst, dann schreib ordentliche Unit-Tests.
Code wäre durchaus "sicherer", wenn man weniger an NPEs denken müsste. Die Sprache Nice erlaubt zum Beispiel keine ``null``-Werte, wenn man nicht explizit bei der Deklaration angibt, dass die Variable auch den Wert ``null`` annehmen darf. Denn das braucht man ja eigentlich gar nicht so häufig -- meistens sorgt man ja dafür, dass die Variablen "ordentliche" Werte enthalten.
Java würde ich übrigens nicht als "rein objektorientiert" beschreiben. Dafür gibt es zu viele Sprachelemente, die keine Objekte sind. Primitive Typen und Klassen zum Beispiel. Da ist Python schon "objektorientierter". Aber immer noch nicht so weit wie Io, wo es keine Klassen, sondern nur noch Objekte gibt, und auch die "Aufrufe" Nachrichten sind, die sich die Objekte zuschicken, wobei die Nachrichten natürlich auch wieder Objekte sind.
Dein Ansinnen ist einfach nicht lösbar. Du kannst nicht statisch feststellen welche Ausnahmen zur Laufzeit ausgelöst werden könnten.
Wenn Du die Qualität sichern willst, dann schreib ordentliche Unit-Tests.
Auch das ist falsch.ice2k3 hat geschrieben:Mal abgesehen davon kann man die Exception in Java genau so nach oben weiter reichen (mit dem Schlüsselwort throws), das Abfangen der Exception ist nicht Pflicht!
In diesem Fall muss der Aufrufer dann die Fehlerbehandlung übernehmen oder weiterreichen. Ein "Unterschlagen" wie in Python ist somit nicht möglich, spätestens in der Main-Methode wird niemand auf die Idee kommen per throws weiter zu reichen.
Ich klinke mich an dieser Stelle mal aus.
Meine Frage war ob man das Behandeln von Exceptions in Python erzwingen kann. Diese Frage beantwortet man nicht mit Halbwahrheiten über andere Programmiersprachen.
Sparrow
Solange eine Sprache nicht durch die Bank weg statisch typisiert, ist eine solche Forderung ziemlich hanebüchen.
Das Problem mal anders betrachtet, Python unterschlägt keine Exceptions, sondern tut das einzig Richtige, Fehler nach oben durchreichen bis der Standardhandler zuschlägt und eben die Programmausführung stoppt.
Btw ist mit unittests doch einiges zu entlarven und die sind für größere Projekte unablässig.
Das Problem mal anders betrachtet, Python unterschlägt keine Exceptions, sondern tut das einzig Richtige, Fehler nach oben durchreichen bis der Standardhandler zuschlägt und eben die Programmausführung stoppt.
Btw ist mit unittests doch einiges zu entlarven und die sind für größere Projekte unablässig.
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Zu checked vs. unchecked Exceptions kann ich diesen Thread aus de.comp.lang.python empfehlen, wo Ole und Diez über den Nutzen von Checked Exceptions sprechen.
Ich muss sagen, dass ich sie auch fürchterlich lästig finde (ohne IDE sogar noch lästiger als sie sonst schon sind) und das C# als größte Konkurrenz zu Java darauf verzichtet ist auch bezeichnend.
Checked Exceptions gibt es in Python nicht und diese sind auch so nicht möglich.
Ich muss sagen, dass ich sie auch fürchterlich lästig finde (ohne IDE sogar noch lästiger als sie sonst schon sind) und das C# als größte Konkurrenz zu Java darauf verzichtet ist auch bezeichnend.
Checked Exceptions gibt es in Python nicht und diese sind auch so nicht möglich.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice