Hallo zusammen, bei den Methoden meiner C# Applikation kann ich mehrere ErrorCodes als Rückgabewert bekommen. In einem Textfeld schreibe ich immer ob die User-Anfragen erfolgreich durchgeführt sind oder nicht, im Fehlerfall möchte ich aber kein ErrorCode ausgeben, sondern ein dazugehöriges Text. Wie kann ich das am einfachsten handeln? (in einer Art Matrix wo ich mit dem ErrorCode ein String bekommen kann!)
Mach dir eine Hashtable mit Nummer und Text Paaren. So kannst du für jede Nummer einen Text hinterlegen.
1 | public static class MyErrors |
2 | {
|
3 | public const int ERROR_FAIL_1 = 0x8001; |
4 | public const int ERROR_FAIL_2 = 0x8002; |
5 | public const int ERROR_FAIL_3 = 0x8003; |
6 | |
7 | private const string UnknownErrorNumber = "Unknown."; |
8 | |
9 | private static Dictionary<int, string> errorMap = new Dictionary<int, string> |
10 | {
|
11 | { ERROR_FAIL_1, "Fehlertext Beschreibung für Fehler 01" }, |
12 | { ERROR_FAIL_2, "Fehlertext Beschreibung für Fehler 02" }, |
13 | { ERROR_FAIL_3, "Fehlertext Beschreibung für Fehler 03" } |
14 | };
|
15 | |
16 | public static string GetErrorText(int number) |
17 | {
|
18 | if (errorMap.ContainsKey(number)) |
19 | return errorMap[number]; |
20 | return UnknownErrorNumber; |
21 | }
|
22 | }
|
Es gibt sicher jede Menge anderer Ansätze sowas zu lösen. Mit diesem hat man wenigstens alles (Fehlernummern, Fehlertexte) an einer Stelle. Du kannst dann auf die Konstanten zugreifen:
1 | var errNr = MyErrors.ERROR_FAIL_1; |
um den Wert irgendwo zurück zu geben. Und an einer anderen Stelle (Textbox) die Nummer in einen String umwandeln lassen:
1 | textBox.Text = MyErrors.GetErrorText(errNr); |
Fehlercodes besser als Enum definieren und dann per eine "zu Fehlertext" Funktion mit einem switch oder Dictonary. http://msdn.microsoft.com/de-de/library/sbbt4032%28v=vs.80%29.aspx Besser ist i.A. aber das Error Handling über Exceptions.
Läubi .. schrieb: > Besser ist i.A. aber das Error Handling über Exceptions. I.A. gebe ich Dir recht. Aber... ... unter C# sind Exceptions das, was man unter ALLEN Umständen vermeiden sollte. Deren Umsetzung ist extrem langsam. Das simple Werfen und Fangen einer NullReferenceException kann schon mal 1 Sekunde Laufzeit verbraten!!! Das ist leider kein Witz. Ich konnte es auch nicht glauben und habe ein kleines Testprogramm mittels Profiler untersucht und die Aussage bestätigt gefunden. Gruß Markus
Markus V. schrieb: > Deren Umsetzung ist extrem langsam Na und? Exceptions sind kein Returnwert sondern etwas ist "kaputt" man sollte nicht den Fehlerfall optimieren sondern den "common case". Markus V. schrieb: > kann schon mal Naja man findet sicher immer Fälle wo irgendein Spezialfall einem die Suppe versalzt. Dafür ist die Fehlerbehandlung und vor allem die Nachvollziehbarkeit über einen Exceptiontrace meiner Meinung nach unverzichtbar, mal abgesehen davon, dass eine Exeption noch sehr viel Mehr Informationen tragen kann (u.A. halt auch einen Fehlertext) als ein simpler error code (welche eh von den meisten Leuten ignoriert wird ;).
Markus V. schrieb: > unter C# sind Exceptions das, was man unter ALLEN Umständen > vermeiden sollte. kann man überhaupt nicht vermeiden, wenn alles glieferten klassen und methoden haben es schon drin. Dafür müsste man die sprache komplett meiden. > Deren Umsetzung ist extrem langsam. Das simple Werfen und Fangen einer > NullReferenceException kann schon mal 1 Sekunde Laufzeit verbraten!!! > Das ist leider kein Witz. Ich konnte es auch nicht glauben und habe ein > kleines Testprogramm mittels Profiler untersucht und die Aussage > bestätigt gefunden. kann du uns mal das Testprogramm zeigen? hatte es eine extreme Verschachtelungstiefe oder irgendwelche anderne exotischen dinge? Welche Version von .net hast du denn untersucht, es ist ja nicht so die die entwicklung bei 1.1 stehen geblieben ist?
Damit Ihr meine Behauptung nicht einfach nur glauben müsst: Selbst Microsoft räumt ein, dass es Performanceprobleme geben kann. http://msdn.microsoft.com/en-us/library/ms229009.aspx @Läubi Ich hatte ja geschrieben, dass ich Dir im Allgemeinen recht gebe. Meine Kollegen und ich durften das Problem auf die harte Tour kennen lernen. Wir hatten Exceptions dazu verwendet, um in der Software Zustände, die nicht ganz der erwarteten Norm entsprachen, mit Exceptions ein paar Ebenen höher zu behandeln. Keine gute Idee, in C#. Zumindest dann nicht, wenn diese Zustände annähernd regelmäßig auftreten. Ich habe das Testprogramm leider nicht mehr greifbar. Es war aber ein eigens konstruiertes Beispiel, ausschließlich dazu da, um die Laufzeit von throw/catch zu testen. Die Aufruftiefe war maximal 1 oder 2 Calls. Dort eine neue NullReferenceExcption erzeugt, geworfen und diese dann im Hauptprogramm per catch gefangen. Es dürfte damals mit VS2005, also .NET 2.0 gewesen sein. Mit .NET 1.1 habe ich nie was gemacht. Gruß Markus
Also warum man heute noch alles mit Exceptions lösen muss verstehe ich wirklich nicht. Errorcodes als Outparameter kann man bei der Programmierung nicht übersehen. Exceptions schon.
Sebastian L. schrieb: > Also warum man heute noch alles mit Exceptions lösen muss verstehe ich > wirklich nicht. > > Errorcodes als Outparameter kann man bei der Programmierung nicht > übersehen. Exceptions schon. weil man sich damit viel code sparen kann, das ständig abgefrage von Return parameter nervt und auserdem kann man immer nur ein wert zurückgeben entweder einen Fehler oder einen Wert. In einem Fehlercode kann man auch keine Weiteren info reinpacken. Ich finde Exceptions gut.
Ob ich jetzt auf einen Errorcode prüfe oder eine exception fange. Da kann ich mit einem errorcode ganz normal in meinem programm fortfahren und darauf reagieren. nach jedem funktionsaufruf try catch ist doch blöde. Peter II schrieb: > auserdem kann man immer nur ein wert > zurückgeben entweder einen Fehler oder einen Wert das geht mit referenzen und out paramtern schon ganz gut
Da hab ich doch auch gleich den passenden artikel noch gefunden http://www.guidetocsharp.de/ExceptionHandling.aspx "Leistung und Ressourcenbedarf Im Zusammenhang mit Ausnahmen liest und hört man häufig, dass diese nicht eingesetzt werden sollten, da sie sehr leistungshungrig seien. Aus dieser Aussage ergibt sich direkt die Frage, wann Ausnahmen überhaupt eingesetzt werden sollten. Prinzipiell ergibt sich die Antwort auf diese Frage bereits aus dem Begriff einer Ausnahme: Sie stellen Ausnahmesituationen dar. Das heißt, Ausnahmen sind explizit nicht dazu gedacht, bedenkenlos an den verschiedensten Stellen innerhalb einer Anwendung eingesetzt zu werden. Sofern es möglich ist, einen Fehler im Vorfeld abzufangen, sollte dies dem Einsatz einer Ausnahme vorgezogen werden. Beispielsweise würde man in dem Beispiel, das die DivideByZeroException abfängt, in der Praxis keine Ausnahme einsetzen, sondern im Vorfeld mit Hilfe einer if-Abfrage prüfen, ob durch 0 geteilt werden soll. Insbesondere, wenn solche Berechnungen innerhalb von Schleifen auftreten, kann dadurch die Leistung der Anwendung durchaus gesteigert werden. Dies liegt daran, dass für jede Ausnahme, die ausgelöst wird, der Aufrufstapel ermittelt werden muss, was bei einer entsprechend tiefen Verschachtelung von Methodenaufrufen unter Umständen aufwändig sein kann. Obwohl Ausnahmen also nicht wahlfrei eingesetzt werden sollten, gibt es dennoch Fälle, in denen ihr Einsatz nicht verzichtbar ist. Dann nämlich, wenn Fehler nicht erwartbar sind und auf Ausnahmesituationen reagiert werden muss. In einem solchen Fall ist es in der Regel allerdings ohnehin nötig, den Benutzer zu informieren und ihn das weitere Vorgehen bestimmen zu lassen, weshalb es in einer solchen Situation nicht darauf ankommt, ob eine Ausnahme schnell oder langsam erzeugt wird - die Anwendung gelangt auf beide Arten zum Stillstand. Zusammengefasst lässt sich also sagen, dass Ausnahmen entgegen ihrem Ruf durchaus eingesetzt werden können, dass dies allerdings gezielt und mit Bedacht geschehen sollte. Insbesondere sollten Fehlersituationen bereits im Vorfeld vermieden werden, sofern dies möglich ist." Fazit. In einem sauberem Modell sollten nach guter Anforderungsanalyse sehr wenige Exceptions drin sein.
Sebastian L. schrieb: > Fazit. In einem sauberem Modell sollten nach guter Anforderungsanalyse > sehr wenige Exceptions drin sein. Nö, es sollten nur sehr wenige auftreten aber enthalten können beliebig viele sein, gerade in Unit-Tests sollte man auch testen, dass in Fehler/Ausnahmesituationen Exceptions auch tatsächlich geworfen werden. Auch bedeutet eine Exception nicht das man sie überall fangen muss (im Gegensatz zu einem Returnwert) "Pseudobeispiel":
1 | function String readMyData() {
|
2 | fh = open("blub.txt")
|
3 | line = readLine() |
4 | close(fh) |
5 | return line; |
6 | } |
Hier muss bei open/read/(close) eine Fehlerbehandlung stehen und der "Schreiber" der Funktion muß wiederum für jeden verschiedenen Fall idealerweise einen anderen returnwert liefern sodass z.B. fehlerhaftes öffnen/datei nicht vorhanden/keine Rechte/fehler beim Lesen/... vom AUfrufer unterschieden werden können. Mit Exceptions deklariere ich einfach das meine Funktion IOExceptions wirft. Die Verwendeten Funktionen ihrerseits werfen FileNotFound/Permissiondenied/ReadError welche von IOException ableiten. Der Aufrufer kann (muss aber nicht wenn er seinerseits die Exception wieder weitergibt) nun die Fehler behandeln oder nicht, und für den "Schreiberling" ist es völlig egal ob die Exception in der ersten zweiten oder dritten Zeile auftrat und was es alles für Fehlersituationen geben könnte...
natürlich muss ich mich um exceptions kümmern. Nicht gefangene exceptions reißen doch das ganze programm nieder. Wie gibst du dass dann an den Benutzer weiter. "Tut mir leid. Die Datei konnte nicht gelesen werden. Warum keine Ahnung." Tolles Programm
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.