Hallo Leute,
ich habe hier mal etwas Quellcode

Code :

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38

//Diese Funktion überprüft ob eine bestimmte Datei in einem bestimmten Pfad vorhanden ist private bool ResourceExist(string strPath, string strFile) {     return File.Exists(strPath+"\\"+strFile); }   //Diese Funktion liest die Daten aus einer Resource Datei //und gibt eine entsprechende Exception zurück private Exception ResourceRead(string strPath, string strFile) {     Exception ex;     if(ResourceExist(strPath, strFile))     {         try         {             System.Resources.ResourceReader resReader = new System.Resources.ResourceReader(strPath+"\\"+strFile);     IDictionaryEnumerator IDE = resReader.GetEnumerator();             while( IDE.MoveNext())             {     if(IDE.Key.ToString() == "Administrator")         strKennwort = IDE.Value.ToString();       if(IDE.Key.ToString() == "Benutzer")         alBenutzer = (ArrayList)IDE.Value;             }             resReader.Close();             return ex = null;         }         catch(Exception e)         {     return e;         }     }     else     {         return ex = new Exception("Diese Datei '"+strPath+"\\"+strFile+"' existriert nicht.");     } }

Ich möchte euch mal nach eurer konstruktive Meinung fragen zu diesem Quellcode, wie man es vielleicht noch besser nachen könnten
Vielen Dank und bis dann

Oh Junge, was'n das?
Seit wann gibt man eine Exception als Rückgabewert zurück?
Exception Fehlernummer - Thread

Versuch bitte nicht die Welt neu zu erfinden. Aus den 36 Zeilen kannst 1 machen.

Code :

1	string sMessage = new RessourceManager( typeof(MyClass) ).GetString( "Administrator" );

Btw. schonmal was von Path.Combine gehört?

Code :

1	Path.Combine( strPath, strFile );

Btw.:

Code :

1	"\\" == @"\" == Path.DirectorySeparatorChar

PS.: Die Netiquette

Hallo Leute,

Seit wann gibt man eine Exception als Rückgabewert zurück?

Das weiß ich nicht, ich habe gedacht, das wenn in der Funktion ein Exception auftritt dann gebe ich sie zurück um im Button_Click darauf reagieren zu können.

Und mit dem Beispiel Exception Fehlernummer - Thread komme ich nicht ganz mit klar.
Wie soll ich es denn sonst machen, die Exception schon in der Funktion auswerten und dann die Funktion abbrechen?
Bis Dann

Wie währe es wenn deine Funktion einfach ein true oder false oder einen FehlerCode zurück gibt?
Das was Du machst produziert einen sinnlosen Overhead.
Norbert hat mit oft genug den Kopf diesbezüglich gewaschen.

Wie soll ich es denn sonst machen, die Exception schon in der Funktion auswerten und dann die Funktion abbrechen?

Mensch Du verblüffst mich. Das ist sogar ein OOP gerechter Ansatz. Weiter so!

Bis irgendwann.
PS.: Ausserdem heisse ich nicht Leute.

Von euch hat niemand den Sinn und Zweck von Exceptions verstanden, oder?

Inwiefern meinst Du das?
Sollte eine Funktion nicht anstatt der Exception den Status/Resultat der Aktion zurückgeben.
Ist doch nicht OOP gerecht das ausserhalb abzuhandeln.

Eine Exception als Rückgabewert ist SCHWACHSINN.
Programmflusssteuerung via Exceptions ist SCHWACHSINN.

Code :

1 2 3 4

private bool ResourceExist(string strPath, string strFile) {     return File.Exists(strPath+"\\"+strFile); }

ist auch Schwachsinn.

Usw.

Sorry, aber es wird mir einfach schlecht wenn ich sowas lese und dann auch noch ungestützte Behauptungen über Exceptions usw.

Und daher mach ich mir einfach mal die Mühe und schreib ein oder mehrere Tutorials zu solchen Themen und dann wird darauf verwiesen. Und wenns jemand net findet, dann nagel ich ihm das persönlich aufs Hirn

Nehmt es mir net böse, aber lests euch doch diverseste Resourcen im Netz zu diesem Thema durch. Ihr könnts doch eh alle englisch. Kaufts euch Bücher zu unterschiedlichen Themen. So schwer ises ja net. Da platzt einem wirklich der Kragen.

Alter, ich schreib auch noch eines, wann eigene Methoden Sinn machen und wann nicht ...

OK Norbert und was sollte dies hier :

Eine Exception als Rückgabewert ist SCHWACHSINN.
Programmflusssteuerung via Exceptions ist SCHWACHSINN.

Code :

1 2 3 4

private bool ResourceExist(string strPath, string strFile) {     return File.Exists(strPath+"\\"+strFile); }

ist auch Schwachsinn.

Usw.

Sorry, aber es wird mir einfach schlecht wenn ich sowas lese und dann auch noch ungestützte Behauptungen über Exceptions usw.

Und daher mach ich mir einfach mal die Mühe und schreib ein oder mehrere Tutorials zu solchen Themen und dann wird darauf verwiesen. Und wenns jemand net findet, dann nagel ich ihm das persönlich aufs Hirn

Nehmt es mir net böse, aber lests euch doch diverseste Resourcen im Netz zu diesem Thema durch. Ihr könnts doch eh alle englisch. Kaufts euch Bücher zu unterschiedlichen Themen. So schwer ises ja net. Da platzt einem wirklich der Kragen.

Alter, ich schreib auch noch eines, wann eigene Methoden Sinn machen und wann nicht ...

daraus werden ich jetzt auch nicht schlauer.
Wie soll ich das nun machen mit den Exception?

Zitat von Norbert Eder

Eine Exception als Rückgabewert ist SCHWACHSINN.
Programmflusssteuerung via Exceptions ist SCHWACHSINN.

Code :

1 2 3 4

private bool ResourceExist(string strPath, string strFile) {     return File.Exists(strPath+"\\"+strFile); }

ist auch Schwachsinn.

Sag ich doch.
Und unterstelle mit bitte nicht das ich Exceptions als Programmflusssteuerung
(Scheiss neue deutsche Rechtscheibung) verwende.
Das geht aus meinen Vorschlägen nicht hervor. Dessen bin ich mir sicher.
Ich mache Vorschläge zur Abhandlung derer. Das man auf alles mit Logik prüfen muss ist mir klar.
Da waren wir uns sogar einig.
Codenavigation durch Exceptions? - Thread
Wenn ichs nicht verstanden hab, das zeig es mir bitte. Vielleicht versteh ich's ja doch nicht.
Du weisst ich hab damals auch ganz schön triviale Schwierigkeiten, wie der Revent hier gehabt.

Wie du das ganze machst hängt auch davon ab, wo deine Methoden drinnen sind. In einer eigenen Klasse, unter einer Form etc. Das weiß ich ja alles nicht. Nur eine Exception per return zurückzugeben ist äußerst übel.

Deine Methode ResourceExist is absolut umsonst. Denn das kannst auch mit dem File.Exists alleine abfakeln.

Dann mal eben bekannt geben WO diese Methode drinnen ist -> Klasse, Form etc. Wenns nämlich in einer Form ist, dann kannst ja ohnehin gleich eine MessageBox ausgeben lassen. Hast du die Methode in eine Klasse ausgelagert, dann gibts genauso mehrere Möglichkeiten. Das ganze Geschichterl mit Fehlernummern etc. vergiss gleich mal. Das macht wirklich nur ganz ganz selten Sinn.

Wenn du schon eine Exception wirfst, dann bitte mit throw new Exception .. wobei Exception hier die Basis-Exception ist. Davon gibts Ableitungen die feiner granulieren. Ebenso kannst deine eigenen Exceptions basteln.

Dann stellst sich bei dir die Frage was du mit deiner Exception erreichen willst? Was soll denn passieren wenn die Exception geworfen wird?

Zitat von cosmochaosmaker

Sag ich doch.
Und unterstelle mit bitte nicht das ich Exceptions als Programmflusssteuerung
(Scheiss neue deutsche Rechtscheibung) verwende.
Das geht aus meinen Vorschlägen nicht hervor. Dessen bin ich mir sicher.
Ich mache Vorschläge zur Abhandlung derer. Das man auf alles mit Logik prüfen muss ist mir klar.
Da waren wir uns sogar einig.
Codenavigation durch Exceptions? - Thread
Wenn ichs nicht verstanden hab, das zeig es mir bitte. Vielleicht versteh ich's ja doch nicht.
Du weisst ich hab damals auch ganz schön triviale Schwierigkeiten, wie der Revent hier gehabt.

Ich unterstelle nichts. Das waren wertfreie Aussagen von mir, die alle zu Herzen nehmen sollten. Sonst nichts. Musst dich also nicht persönlich angegriffen fühlen

Hallo Leute,
mit die RescourceExist() Funktion ist unglücklich, ich habe sie entfernt.
Da habt Ihr recht.
Die andere Funktion ist in der Form mit drin und Du hast recht ob ich in der Funktion oder in der Form eine MessageBox zeige ist dann schon fast egal.
Wie ist das mit einer Klasse in der ich alle Funktionen rein packe die ich für das Programm brauche oder soll ich sie lieber in der Form belassen?
Ich könnte dann ja auch alle globalen Variablen mit in die Klasse packen.
Ok dann wäre das alles schön getrennt und der Code liest sich dann vielleicht besser.
Was meint Ihr?

Du arbeitest mit C# und nicht in VB Daher solltest du dich um die Grundsätze der OOP kümmern bzw. dich da einfach mal einlesen.

Wichtig ist, dass du deinen Code von der Darstellung trennst. D.h. keinen Code in deiner Form. Ausser dem Aufruf deiner Objekte und das Anzeigen der Ergebnisse.

Gliedere deinen Code in Klassen aus. Und zwar nicht alle deine Methoden in eine Klasse, sondern getrennt nach Aufgabenbereich.

Hallo Norbert,
hast Du den ein gute Lektüre über OOP.
Und was meinst Du mit

Du arbeitest mit C# und nicht in VB

Wichtig ist, dass du deinen Code von der Darstellung trennst. D.h. keinen Code in deiner Form.

Heißt das beim aufruf von Button_Click eine Funktion in einer Klasse aufrufen in der dann das gemacht wird was eigendlich in Button_Click geschehen würde.

Was hat das für ein Vorteil?
bis Dann

Zitat von Reverent

hast Du den ein gute Lektüre über OOP.

Zu OOP gibts genug im Netz. Einfach mal suchen. Ein Einstiegspunkt wäre zb:
http://en.wikipedia.org/wiki/Object-...ed_programming

Zitat von Reverent

Und was meinst Du mit

Das soll heissen: Nutz die OOP und nicht so einen Wurschtelcode wie unter VB.

Zitat von Reverent

Heißt das beim aufruf von Button_Click eine Funktion in einer Klasse aufrufen in der dann das gemacht wird was eigendlich in Button_Click geschehen würde.

Genau. Wobei bitte nicht von einer Klasse auf die Form zugreifen. Mach das über Rückgabeparameter, Structs etc.

Zitat von Reverent

Was hat das für ein Vorteil?

* Code getrennt von der Visualisierung, d.h. du kannst zb ohne viel Aufwand das Frontend austauschen
* verbesserte Wartbarkeit
* eine bessere Übersicht
* usw.