[C#] Fehlerklasse

LordDeath

Erfahrenes Mitglied
Morgen.

Ich schreib zur Zeit an einer Medienverwaltung. Da das ein größeres Projekt ist, können viele Fehler auftreten. Nun stellt sich mir die Frage wie ich die Fehler managen kann. Mir ist jetzt die Idee gekommen eine Fehlerklasse zu schreiben, die Zahlen (int Werte) mit nem Text Verknüpft. Desweitern würde ich dann jedem Fehler ne Nummer verpassen und könnte die dann so auswerten. Was haltet ihr davon? Wie kann ich es besser lösen?

BloodyGreetz
 
Finde ich nicht so gut. Damit gehst du wieder zurück zu Visual Basic anno 1900 ;-)

Prinzipiell solltest du erstens Fehler vermeiden, zweitens sofern welche auftreten abfangen und entsprechend behandeln. Fehlernummern hättest du so auch dabei, wenn du dir die Exceptions genau ansiehst.

Sollte ein Fehler mal nicht zu behandeln sein, dann kannst du dem User auch anzeigen, was er tun kann, um diesen Fehler zu beheben bzw. den Stacktrace, wenn der Fehler an den Entwickler weiterzuleiten ist.
 
Hi!

Hm ... ich finde die Idee nicht schlecht. Du könntest natürlich auch eigene Exception-Klassenstrukturen anlegen, was du wahrscheinlich eh machen wirst nehm ich an, und die Fehlermeldungen strukturiert irgendwo ablegen, z.B. xml datei, datenbank (übertrieben denke ich) und dann, wie du beschrieben hast, mittels ID bequem auslesen.

Gruß
TOM
 
Hm... das Argument von Norbert ist nicht so schlecht. Du könntest in den Exceptions auch gleich die Fehlermeldungen einbauen, bzw. eben Vorschläge bringen. Andererseits sind Vorschläge nicht Teil einer Exception, und sollten, da sich ja auch etwas daran ändern kann, meiner Meinung nach, nicht direkt in einer Exception behandelt werden.

TOM
 
Mir stellt sich dann nur die Frage. Ich arbeite mit DLL`s, und da einfach die Excpetions ausgeben? Das ist meiner Meinung nach nicht Sinn und Zweck der Sache, außerdem weiß ich nicht ob das Main Win oder Konsole ist, dementsprechend kann ich auch die Fehler nicht ausgeben.

Norbert Eder hat gesagt.:
Prinzipiell solltest du erstens Fehler vermeiden,

Wenn der User die Fehler verursacht z.B. Tippfehler oder sonstiges hab ich als Entwickler schlechte Karten :) .

BloodyGreetz
 
Zuletzt bearbeitet:
Wie meinst du nicht sinn und zweckmäßig bei DLL's die Fehler nicht abzufangen? Ich muss gestehn, ich hab nur sehr wenig mit DLLs zu tun, aber im Grunde sind das ja nur Komponenten die du verwendest, oder? D.h. z.b. in C# könntest du die Fehler abfangen ... .

@Norbert: keine Fehler ist im Software Engineering nahezu unmöglich, oder kannst du mir eine Applikation nennen bei der zu 100% keine Fehler auftreten können? :)

Gruß
TOM
 
Nein, ist kein Problem.

In einer Exception sind alle Angaben bereits drinnen (Fehlermeldung, Stacktrace etc.). Eventuell musst du dir für bestimmte Dinge noch eigene Exceptions bauen, was aber nicht das Problem sein soll.

Wenn eine Exception auftritt, dann reichst du die weiter (mittels throw). In einer DLL geworfene Exceptions kannst ja nicht anzeigen, daher weiter rausreichen. Die Exception wird dann z.B. in der Consolen-Anwendung oder in der Windows.Forms-Anwendung geworfen und kann dort dann angezeigt werden.

Hierbei musst du natürlich unterscheiden welche "Art" von Exception das ist, sprich, kannst du diese innerhalb der DLL behandeln, oder wird eine User-Interaktion erwartet.
 
Hallo LordDeath!
Wenn der User die Fehler verursacht z.B. Tippfehler oder sonstiges hab ich als Entwickler schlechte Karten
Aber Exceptions als Programmflusssteuerung zu verwenden ist absoluter Schwachsinn!
[post=928531]Re: Codenavigation durch Exceptions? - Post[/post]

[thread=213759]Fehlernummer - Thread[/thread]

Btw. [thread=162023]Codenavigation durch Exceptions? - Thread[/thread]

MfG, cosmo
 
TommyMo hat gesagt.:
@Norbert: keine Fehler ist im Software Engineering nahezu unmöglich, oder kannst du mir eine Applikation nennen bei der zu 100% keine Fehler auftreten können? :)

Hmm .. Java-Hello-World, C#-Hello-World .. *g*. Nein, im Ernst: Du hast natürlich recht. 100% bugfree ist eher unwahrscheinlich. Dennoch sollten alle möglichen Fehlerquellen minimiert werden. Dazu braucht es gar nicht soviel. Ich sage hier nur Testklassen. Damit kann das Verhalten der Software sehr gut (und vor allem ständig) überwacht und eben getestet werden.

Dass Fehler auftreten ist nun mal so. Jeder macht Fehler. Dennoch muss nicht für alles gleich eine Exception bis zum User gehen.

Ein Beispiel um dies zu verdeutlichen:
Unter der Annahme wir verwenden ein Config-File und eben dieses ist nicht vorhanden. Dann wird natürlich beim Zugriff darauf eine Exception FileNotFoundException geworfen. Äußerst unsauber, denn das interessiert den User nicht. Stattdessen, sollte zwar die Exception abgefangen werden, aber im gleichen Zug auch das File angelegt werden. Eventuell muss dann nur mehr der User darauf aufmerksam gemacht werden, dass er noch Einstellungen vorzunehmen hat.

Diese Punkte meinte ich. Hier gilt es in der Tat zu unterscheiden:
1. Was muss der User tatsächlich an Fehlermeldungen bekommen?
2. Was kann ich dem User zumuten?
3. Was kann ich in der Software selbst abfangen und behandeln bzw. lösen.
 
Zurück