Das deutsche Python-Forum

Erstmal bin ich neu in diesem Forum und wage mich nun an ein Projekt für Lan-Partys. Ich habe versucht ein änliches Thema zu finden aber anscheinend gibt es keinen, falls doch tut es mir leid

Programm:
Der Anwender soll eine Lokale IP angeben wie zb: 192.168.0.20. Jetzt soll einfach geprüft werden ob diese vergeben ist. (Mit batch: mit einem Ping befehl). Falls ja wird ausgegeben das diese schon vergeben ist. Jetzt soll der Anwender eine andere angeben zb:
192.168.0.21, falls diese frei ist soll er die IP automatisch ändern.

Ich habe mir befehle rausgesucht wie zb. Die IP über subprocess mittels netsh zu ändern... Da ich mich aber von der cmd verabschieden will meine erste frage ob es auch in reinem Python geht? Bzw. Ob sich der aufwand überhaupt lohnt

Die IP's zu scannen wird da schon schwieriger ... Und hier frage ich mich ob sich das lohnt, denn ich sehe dieses Projekt von mir als übung für mich, da ich dabei bin Python zu lernen. Wenn der Code zu unübersichtlich wird bringt mir nur die Funktion was und nicht das was ich eigentlich möchte.. Nähmlich lernen. Ich möchte den Code verstehen und daraus lernen sowas in einer batch zu schreiben ist einfach, dass bekomm ich hin, aber ich will kein batch mehr schreiben sondern es in Python versuchen

Mit freundlichen Grüßen
Tryser

/Edit: Ich Programmiere in Python3.2

@TrayserCassa: Die IPs per DHCP vergeben zu lassen ist wahrscheinlich einfacher, insbesondere für die Nutzer, die dann einfach nur ihren Rechner anstöpseln müssen.

Ansonsten ist hier tatsächlich die Frage ob das nicht in einem Python-Skript ändert, welches eigentlich nur externe Programme aufruft, und dabei Python letztendlich aufwändiger ist, als das einfach per Batch-Skript zu schreiben.

Achso stimmt schuldige ich habe vergessen warum überhaupt wir feste IP adressen brauchen:

Bei unseren Lan Spielen CoD 4 und 6 brauchen wir feste IP's wie zb.: 192.168.0.20, dabei sind die 192.168.0. vorgegeben und müssen verwendet werden. Warum das so ist ... :K

Jedensfalls kann man bei 18 Leuten das alles noch einzelnd einstellen aber wenn wir mit 36 Leuten eine Lan machen 2 Server aufmachen und jeder eine andere IP braucht (und die Wissen nicht wie man die IP einstellt), dann wird das alles zuviel für mich...

und das schlimmste ist es gibt meistens doppelte und dann grübelt man ne halbe stunde lang warum der server nicht will und stellt fest das irgendeiner die selbe IP hat ...

und deswegen möchte ich zumindest ein check haben ob die vergeben ist =)

@TrayserCassa: Ich sehe immer noch nicht was gegen DHCP spricht. Man kann ja einstellen welche IPs der Server vergibt.

Ein gecrackter MW-2 server? Wir reden nicht von einem Server im World wide web sondern nur im Lokalen Netzwerk

der Host startet den alterIWnet server und danach starten die anderen das Spiel und müssen in der Console "connect *host IP*" eingeben und man kommt in die Lobby.
Man kann nur beitreten wenn:
- Die IP nicht doppelt vorkommt
- Die IP lokal ist 192.168.0.

Also 192.168.0.20 klappt
192.168.1.21 klappt nicht

Ich hab den Server von alterIWnet nicht geschrieben und der war ja auch nicht dazu da um im lokalen netz zu spielen

@TrayserCassa: Ich meinte nicht die Spieleserver (Software) sondern welcher Server/Rechner/Gerät (Hardware) auch immer im lokalen Netz per DHCP Adressen verteilt, also einen DHCP-Server (Software) am Laufen hat.

Dann müsste ich ja erst einen DHCP Server aufsetzten ... (Oder lieg ich da falsch?)

Wie schon erwähnt es geht mir nicht nur um die Funktion (wenn ich das Programm unbedingt bräuchte, dann hätte ich es in 2 Tagen in batch geschrieben) sondern darum das ich das in Python schreibe

Ich hab schonmal das prüfen ob die IP bereits vorhanden ist in python mit dem ping befehl der cmd aufgeschrieben:
Man kann allerdings 192.168.168.168.192 eingeben aber ich glaube so doof ist jetzt keiner

Mit dem subprocess modul komm ich nicht in einklang -.- will nicht so wie ich will da hab ich das mit dem os.system modul gemacht und reicht ja auch vollkommen

@TrayserCassa: `os.system()` reicht nicht vollkommen, sondern diese kaputte Funktion ist mit ein Grund warum es das `subprocess`-Modul gibt. Du kannst zum Beispiel nicht heraus finden von wem eigentlich der Rückgabewert kommt, von der Shell die den Befehl ausführt, oder vom Befehl selbst. Ausserdem ist das da gerade eine riesige Sicherheitslücke über die der Benutzer beliebige Sachen über die Shell ausführen kann.

Die Organisation des Codes ist ungünstig weil an zwei Stellen der Benutzer aufgefordert wird eine IP einzugeben. Da sollte man nur einmal schreiben müssen. Wenn man aus der Schleife eine Endlosschleife macht (``while True:``) die dann im Erfolgsfall mit ``break`` verlassen wird, spart man sich die doppelte Abfrage und auch gleich noch `fail`.

`anzahl` wird nicht verwendet. Die Zuweisung ``IP = ip`` macht nicht viel Sinn, ausserdem sind Namen komplett in Grossbuchstaben per Konvention für Konstanten vorgesehen.

`str()` mit einer literalen Zeichenkette aufzurufen ist sinnfrei. Ausserdem ist der Test nicht das, was Du ausdrücken möchtest. Die IP soll das ja nicht *enthalten*, sondern damit *anfangen*. Für diesen Test gibt es auf Zeichenketten eine Methode. Allerdings könnte man sich auch fragen warum man den Benutzer überhaupt einen Wert eingeben lässt, dessen Präfix sowieso schon fest steht. Man könnte ihn auch nur den Teil eingeben lassen, auf den er tatsächlich einen Einfluss hat.

@TrayserCassa: `os.system()` reicht nicht vollkommen, sondern diese kaputte Funktion ist mit ein Grund warum es das `subprocess`-Modul gibt. Du kannst zum Beispiel nicht heraus finden von wem eigentlich der Rückgabewert kommt, von der Shell die den Befehl ausführt, oder vom Befehl selbst. Ausserdem ist das da gerade eine riesige Sicherheitslücke über die der Benutzer beliebige Sachen über die Shell ausführen kann.

Ok wird bearbeitet

Die Organisation des Codes ist ungünstig weil an zwei Stellen der Benutzer aufgefordert wird eine IP einzugeben. Da sollte man nur einmal schreiben müssen. Wenn man aus der Schleife eine Endlosschleife macht (``while True:``) die dann im Erfolgsfall mit ``break`` verlassen wird, spart man sich die doppelte Abfrage und auch gleich noch `fail`.

Geändert und eingesehen

`anzahl` wird nicht verwendet. Die Zuweisung ``IP = ip`` macht nicht viel Sinn, ausserdem sind Namen komplett in Grossbuchstaben per Konvention für Konstanten vorgesehen.

ok wusste ich nicht ebenfalls geändert.

`str()` mit einer literalen Zeichenkette aufzurufen ist sinnfrei. Ausserdem ist der Test nicht das, was Du ausdrücken möchtest. Die IP soll das ja nicht *enthalten*, sondern damit *anfangen*. Für diesen Test gibt es auf Zeichenketten eine Methode. Allerdings könnte man sich auch fragen warum man den Benutzer überhaupt einen Wert eingeben lässt, dessen Präfix sowieso schon fest steht. Man könnte ihn auch nur den Teil eingeben lassen, auf den er tatsächlich einen Einfluss hat.

Stimmt ... Geändert


Erstmal danke ich dir herzlich für die Tipps und vorallem für die Verbesserungsvorschläge Allerdings frage ich mich, warum man in einem so rauen umgangston mit einem Neuling in Python, so umgeht?

Ob es daran liegt das ich noch nie ein Betrag verfasst habe und gleich mit einer Frage anfange?
An den Rechtschreibfehlern?
An dem Code?

mfg
Trayser

TrayserCassa hat geschrieben:Allerdings frage ich mich, warum man in einem so rauen umgangston mit einem Neuling in Python, so umgeht?

Der Ton ist nicht rau, sondern sachlich

EyDu hat geschrieben:

TrayserCassa hat geschrieben:Allerdings frage ich mich, warum man in einem so rauen umgangston mit einem Neuling in Python, so umgeht?

Der Ton ist nicht rau, sondern sachlich

ok bevor ich das nächste mal Code poste mach ich ihn auch schöner

Eine Frage bleibt noch ... kann ich die IP auch mit einem Modul ändern oder über netsh?

mfg
Trayser

Ok hier mal der bearbeitet Code
das mit netsh noch nicht getestet
was haltet Ihr davon?

mfg
Trayser

@TrayserCassa: Nackte ``except:``\s ohne Angabe von konkreten Ausnahmen, die man im ``try``-Block erwartet, sollte man unbedingt vermeiden. Denn dann werden *alle* Ausnahmen im ``except``-Block behandelt, auch solche, mit denen überhaupt nicht gerechnet hat. Und für die wird dann etwas unpassendes getan. Zum Beispiel könnte man sich im ``try``-Block bei einem Namen vertippen und der Benutzer bekommt dann die Ausgabe, dass es sich nicht um eine Zahl handelt. Obwohl er vielleicht eine eingegeben hat. Und als Programmierer darf man dann einen Fehler suchen zu dem man nie eine Ausnahme zu Gesicht bekommt.

Von ``continue`` würde ich persönlich Abstand nehmen. Das ist ein Sprung aus einer verschachtelten Struktur an den Schleifenanfang, den man der Quelltextstruktur nicht so ohne weiteres ansieht. Ausserdem verbaut man sich die Möglichkeit etwas am Ende von jedem Schleifendurchlauf zu tun, weil das ``continue`` ja so eine Art Abkürzung zum Anfang der Schleife nimmt. Das ``continue`` am Ende der Schleife im ``else`` ist zudem überflüssig, denn dort würde die Schleifenausführung auch ohne diese Anweisung von vorne beginnen. Statt des anderen ``continue`` hätte man zum ``except`` ein ``else`` verwenden können, oder die `is_decimal()`-Methode auf Zeichenketten anstelle des `int()`-Aufrufs zum Testen.

Beim `subprocess.call()` am Ende übergibst Du die Argumente falsch. Das wird ja nicht von einer Shell in einzelne Argumente zerlegt, sondern muss vom Programmierer als Liste angegeben werden. Ausserdem enthält `net` bestimmt nicht das was Du erwartet hast. In Python fügen doppelte doppelte Anführungszeichen *nicht* doppelte Anführungszeichen in ein Zeichenkettenliteral ein: Was hier passiert sind einfach mehrere Zeichenkettenliterale die direkt nebeneinander stehen. Und der Compiler fügt literale Zeichenketten, die nur durch gar nichts oder „whitespace”-Zeichen getrennt sind, beim Übersetzen automatisch zu einer Zeichenkette zusammen: Die 255 sollte man vielleicht auch nicht eingeben. Das kann je nach Subnetzmaske eine spezielle Bedeutung haben. Man könnte auch testen ob die Zahl zwischen 1 und 254 (inklusive) liegt.

Vielleicht noch besser oder einfacher wäre es wenn Du den Benutzer nicht fragst, sondern eine Liste mit Zahlen von 1 bis 254 erzeugst, die mischst (random.shuffle()) und dann so lange probierst, bist Du eine freie IP gefunden hast. Das Mischen damit mehrere Leute, die das gleichzeitig laufen lassen, nicht so leicht „kollidieren”.

@TrayserCassa: Nackte ``except:``\s ohne Angabe von konkreten Ausnahmen, die man im ``try``-Block erwartet, sollte man unbedingt vermeiden. Denn dann werden *alle* Ausnahmen im ``except``-Block behandelt, auch solche, mit denen überhaupt nicht gerechnet hat. Und für die wird dann etwas unpassendes getan. Zum Beispiel könnte man sich im ``try``-Block bei einem Namen vertippen und der Benutzer bekommt dann die Ausgabe, dass es sich nicht um eine Zahl handelt. Obwohl er vielleicht eine eingegeben hat. Und als Programmierer darf man dann einen Fehler suchen zu dem man nie eine Ausnahme zu Gesicht bekommt.

Deshalb Teste ich doch mein Code vorerst Das haben ich ebenfalls aus dem Buch

Von ``continue`` würde ich persönlich Abstand nehmen. Das ist ein Sprung aus einer verschachtelten Struktur an den Schleifenanfang, den man der Quelltextstruktur nicht so ohne weiteres ansieht. Ausserdem verbaut man sich die Möglichkeit etwas am Ende von jedem Schleifendurchlauf zu tun, weil das ``continue`` ja so eine Art Abkürzung zum Anfang der Schleife nimmt.

hmm Aber Genau das will ich ja falls was nicht stimmt fang wieder von vorne an Ich wüsste spontan auch nicht wie ich sonst schreiben müsste ... Ich bin ein Anfänger im bereich Python und Lese das Buch dazu (Einstieg in Python) und da hab ich es ja her Ich verbaue mir was nur wenn ich wichtige variabeln nicht da drüber schreibe und daran werde ich ja nochwohl denken

Das ``continue`` am Ende der Schleife im ``else`` ist zudem überflüssig, denn dort würde die Schleifenausführung auch ohne diese Anweisung von vorne beginnen. Statt des anderen ``continue`` hätte man zum ``except`` ein ``else`` verwenden können, oder die `is_decimal()`-Methode auf Zeichenketten anstelle des `int()`-Aufrufs zum Testen.

ok das "continue" ist überflüssig ich poliere den Code eben schnell
except --> else :K Kein Plan was du meinst ich kenn verzweigung nur mit except
"is_decimal()" Ich verwende ausschließlich Module die ich kenne aus dem Buch Ergebniss ist in dem Fall ja das selbe oder?

Beim `subprocess.call()` am Ende übergibst Du die Argumente falsch. Das wird ja nicht von einer Shell in einzelne Argumente zerlegt, sondern muss vom Programmierer als Liste angegeben werden.

also so?:
subprocess.call(["netsh", "IP" "set"]shell=True) (Nur als beispiel IP und set.)

Ausserdem enthält `net` bestimmt nicht das was Du erwartet hast. In Python fügen doppelte doppelte Anführungszeichen *nicht* doppelte Anführungszeichen in ein Zeichenkettenliteral ein:
Code:
In [1]: "interface ip set address ""Local Area Connection"" static "
Out[1]: 'interface ip set address Local Area Connection static '

Was hier passiert sind einfach mehrere Zeichenkettenliterale die direkt nebeneinander stehen. Und der Compiler fügt literale Zeichenketten, die nur durch gar nichts oder „whitespace”-Zeichen getrennt sind, beim Übersetzen automatisch zu einer Zeichenkette zusammen:

Ja habs bemerkt bloß kann ich in diesem Fall die "" auch weglassen, da Sie im befahl netsh nicht weiter wichtig sind ich habe extra eine Variabel genommen und dahinter print(net) eingesetzt die ausgabe kopiert und in die cmd mit dem befehl eingegeben Klappt nicht ... Siehe unten

Die 255 sollte man vielleicht auch nicht eingeben. Das kann je nach Subnetzmaske eine spezielle Bedeutung haben. Man könnte auch testen ob die Zahl zwischen 1 und 254 (inklusive) liegt.

ok bearbeitet, aber wir reden nur von einem Programm was Freunde anwenden, wenn ich auch anwesend bin Falls es dann Probleme gibt

Vielleicht noch besser oder einfacher wäre es wenn Du den Benutzer nicht fragst, sondern eine Liste mit Zahlen von 1 bis 254 erzeugst, die mischst (random.shuffle()) und dann so lange probierst, bist Du eine freie IP gefunden hast. Das Mischen damit mehrere Leute, die das gleichzeitig laufen lassen, nicht so leicht „kollidieren”.

Die Idee ist mir auch schon gekommen, allerdings ist unser standart Host 192.168.0.20 und dann gibs von manchen wieder extra wünsche und die wollen dann mal Host sein und so ein Kindermisst mehr
Viel besser wäre es eine Zufalls IP generieren zu lassen und dann den Anwender zu fragen ob er die benutzen will oder doch lieber eine eintippen möchte Aber soll nur ein Übungsscript werden

Neues Problem
Netsh kann nur unter Administrator rechten ausgeführt werden
Eine Lösung wäre aus dem Code eine exe zu machen (p2exe) aber geht das auch für Code aus Python3.2 ?
Oder eine Lösung die für ein Einsteiger noch übersichtlich ist

ok Danke bis jetzt klappt alles bis auf der befehl mit netsh..
mfg
Trayser

@TrayserCassa: Das mit dem ``except:`` hat nichts damit zu tun ob Du den Code testest oder nicht. Das ist ein Problem wenn Ausnahmen auftreten mit denen Du nicht gerechnet hast, also auch nicht beim Testen, denn wenn Du damit gerechnet hättest, dann hättest Du dafür ja einen Test durchgeführt. Und wenn Du keine Unit-Tests hast, dann müsstest Du manuell nach jeder Programmänderung die Tests für die geänderte Stelle manuell machen. Und zwar jedes mal die selben. So aus dem Kopf.

Du musst die Bedingung für das ``continue`` nur umdrehen. Also nicht gehe zum Anfang wenn etwas nicht stimmt, sondern mache dieses hier *wenn* alles stimmt. Zu einer Ausnahmebehandlung gehört ein ``try`` und dann gibt es noch ``except``, ``finally``, und ``else``. Ein ``else``-Block wird ausgeführt, wenn im ``try``-Block *keine* Ausnahme aufgetreten ist. Du solltest neben Deinem Buch eventuell auch mal einen Blick in die Python-Dokumentation werfen. Erwarte nicht, dass in einem Buch wirklich alles vorkommt, was eine Programmiersprache an Syntax bietet. Und auch nicht alle Methoden auf Grunddatentypen. `is_decimal()` ist wie gesagt eine Methode auf Zeichenketten. Da braucht man kein Modul für und mit den Methoden die Zeichenketten bieten, sollte man sich auseinandersetzen. Das sind Grundlagen. Und auch da würde ich nicht erwarten, dass die alle in einem Buch einzeln besprochen werden. Die Python-Dokumentation ist wichtig, für das praktische Arbeiten am Ende wichtiger als ein Lehrbuch.

Das Ergebnis des Tests ist das selbe, allerdings wesentlich einfacher und mit deutlich weniger Quelltext den man verstehen muss. Statt ``try``/``except``/``else`` ist es einfach nur ein ``if`` und dieser Methodenaufruf.

Beim `subprocess.call()` bitte das ``shell=True`` weg lassen. Sonst handelt man sich die gleichen Probleme ein, die `os.system()` hat.

@TrayserCassa: Das mit dem ``except:`` hat nichts damit zu tun ob Du den Code testest oder nicht. Das ist ein Problem wenn Ausnahmen auftreten mit denen Du nicht gerechnet hast, also auch nicht beim Testen, denn wenn Du damit gerechnet hättest, dann hättest Du dafür ja einen Test durchgeführt. Und wenn Du keine Unit-Tests hast, dann müsstest Du manuell nach jeder Programmänderung die Tests für die geänderte Stelle manuell machen. Und zwar jedes mal die selben. So aus dem Kopf.

In diesem Fall wird Try verwendet um zu testen ob das eine zahl ist. Wenn nicht dann neue eingabe ... Wenn ich jetzt was anderes als eine Zahl von 1 bis 255 eingebe, dann soll der den Ping ja nicht ausführen weil das unnötige Arbeit ist. Bei einem Fehler geh nach except und da wird dann gesagt wieder von neuen anfangen. :K Was ist daran falsch?

Du musst die Bedingung für das ``continue`` nur umdrehen. Also nicht gehe zum Anfang wenn etwas nicht stimmt, sondern mache dieses hier *wenn* alles stimmt. Zu einer Ausnahmebehandlung gehört ein ``try`` und dann gibt es noch ``except``, ``finally``, und ``else``. Ein ``else``-Block wird ausgeführt, wenn im ``try``-Block *keine* Ausnahme aufgetreten ist. Du solltest neben Deinem Buch eventuell auch mal einen Blick in die Python-Dokumentation werfen. Erwarte nicht, dass in einem Buch wirklich alles vorkommt, was eine Programmiersprache an Syntax bietet. Und auch nicht alle Methoden auf Grunddatentypen. `is_decimal()` ist wie gesagt eine Methode auf Zeichenketten. Da braucht man kein Modul für und mit den Methoden die Zeichenketten bieten, sollte man sich auseinandersetzen. Das sind Grundlagen. Und auch da würde ich nicht erwarten, dass die alle in einem Buch einzeln besprochen werden. Die Python-Dokumentation ist wichtig, für das praktische Arbeiten am Ende wichtiger als ein Lehrbuch.

Ok danke für den Tipp

Das Ergebnis des Tests ist das selbe, allerdings wesentlich einfacher und mit deutlich weniger Quelltext den man verstehen muss. Statt ``try``/``except``/``else`` ist es einfach nur ein ``if`` und dieser Methodenaufruf.

Stimmt nur trenne ich gerne generell Erfolg und Misserfolg voneinander und eine reine if verzweigung finde ich nicht wirklich übersichtlicher, aber dennoch im Bereich des Möglichen

Beim `subprocess.call()` bitte das ``shell=True`` weg lassen. Sonst handelt man sich die gleichen Probleme ein, die `os.system()` hat.

Dadurch würde die shell wieder zum vorschein kommen und da liegt mein Problem...

ok soweit zum Coden jetzt nur meine Frage noch wie ich netsh als Admin ausführe ...

Und ist schon klar, warum du ein try/except verwendest. Du verwendest es allerdings falsch, da bei dir alle Fehler abgefangen werden, auch wenn diese gar nichts mit der Umwandlung der Zahl zu tun haben. Damit verdeckst du unter Umständen Programmierfehler, welche dann auch noch schwer zu finden sind, weil du falsche Meldungen bekommst und, im schlimmsten Fall, sich das Programm in einem inkonsistenten Zustand befindet und dann an einer Stelle abstürzt, die mit dem eigentlichen Fehler nichts zu tun hat. Mal als Beispiel:
In beiden Beispielen wird die Variable "hier_wird_eine_name_error_geworfen" verwendet, obwohl sie vorher nie angelegt wurde. Wenn du einfach alle Fehler abfängst, so wie du es im Moment macht, dann endet das ganze wie im oberen Beispiel. Der Benutzer gibt die Zahl korrekt ein, in der nächsten Zeile hast du in deinem Programm allerdings einen Fehler gemacht. Die Exception wird abgefangen und es wird einfach behauptet, dass die Eingabe falsch war. Im zweiten Fall hingegen gibt es die korrekte Fehlermeldung.

EyDu hat geschrieben:Und ist schon klar, warum du ein try/except verwendest. Du verwendest es allerdings falsch, da bei dir alle Fehler abgefangen werden, auch wenn diese gar nichts mit der Umwandlung der Zahl zu tun haben. Damit verdeckst du unter Umständen Programmierfehler, welche dann auch noch schwer zu finden sind, weil du falsche Meldungen bekommst und, im schlimmsten Fall, sich das Programm in einem inkonsistenten Zustand befindet und dann an einer Stelle abstürzt, die mit dem eigentlichen Fehler nichts zu tun hat. Mal als Beispiel:

Code: Alles auswählen

>>> try:
...     input("Zahl eingeben: ")
...     hier_wird_eine_name_error_geworfen *= 2
... except:
...     print("Es wurde keine Zahl eingegeben")
... 
Zahl eingeben: 42
42
Es wurde keine Zahl eingegeben

Code: Alles auswählen

>>> try:
...     input("Zahl eingeben: ")
...     hier_wird_eine_name_error_geworfen *= 2
... except ValueError:
...     print("Es wurde keine Zahl eingegeben")
... 
Zahl eingeben: 42
42
Traceback (most recent call last):
  File "<stdin>", line 3, in <module>
NameError: name 'hier_wird_eine_name_error_geworfen' is not defined

In beiden Beispielen wird die Variable "hier_wird_eine_name_error_geworfen" verwendet, obwohl sie vorher nie angelegt wurde. Wenn du einfach alle Fehler abfängst, so wie du es im Moment macht, dann endet das ganze wie im oberen Beispiel. Der Benutzer gibt die Zahl korrekt ein, in der nächsten Zeile hast du in deinem Programm allerdings einen Fehler gemacht. Die Exception wird abgefangen und es wird einfach behauptet, dass die Eingabe falsch war. Im zweiten Fall hingegen gibt es die korrekte Fehlermeldung.

Ahhh ok hat Klick gemacht bloß wo liegt der fehler wenn ich nur eine Zeile in einem Try Zweig habe Aber Ich weiß worauf Ihr beide hinaus wollt Danke für die Tipp's und vorallem um die Bemühungen

mfg
Trayser

Auch in einer Zeile kann man problemlos Fehler einbauen. Oder eine Zeile ändert sich mal. Gerne werden aus einer Zeile auch mal zwei, oder drei, oder mehr. Dann übersieht man leicht, dass irgendwo noch etwas angepasst werden muss und schon hat man einen richtigen Fehler.

Behandle also nur das, was du auch wirklich behandeln kannst. Wenn dir dein Programm dann um die Ohren fliegt, dann hast du immerhin die Chance den Fehler zu beseitigen.