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.

Zitat von Norbert Eder

Prinzipiell solltest du erstens Fehler vermeiden,

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

BloodyGreetz

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

Zitat von TommyMo

Wie meinst du nicht sinn und zweckmäßig bei DLL's die Fehler nicht abzufangen?

Abfangen ja, aber die Fehlerausgabe ist das Problem.

BloodyGreetz

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!
Re: Codenavigation durch Exceptions? - Post

Fehlernummer - Thread

Btw. Codenavigation durch Exceptions? - Thread

MfG, cosmo

Zitat von TommyMo

@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.

Zitat von cosmochaosmaker

Stichwort "Software Ergonomie"

Falsch. Stichwort: Unit Tests, Usability Evaluation (Heuristics, testing, inspection, simulation, etc.)

Nein cosmo, NEIN!!

Setz dich doch einfach mal mit den Stichworten, die ich geliefert habe, auseinander und DANN erst posten.

Ach "Usability Evaluation".
Mist, wie konnt ich den Begriff jetzt nur überlesen.
Aber Du hattest die Ergonomie schon mal mit den 3 Punkten, die Du oben angeführt hast,
in Verbindung gebracht (CodersTalk). Ich ich bin mir IMHO sicher das sie dazu gehören.
Oder hab ich das jetzt falsch verstanden?

Du weisst sicher jetzt auch das dass was wir in D in der Berufsschule zu dem Thema gelernt haben,
nur nonsens ist und oberflächlich Vermittelt wurde.

Sorry nochmal.

Ok danke! Also verwende ich throw um die Exceptions weiterzuleiten die der User behandeln muss. Andere Fehler kann ich dementsprechend gleich intern behandeln siehe Config File.

Danke

BloodyGreetz

Trotzdem solltest du Messages nicht unbedingt löschen, denn dann ist der Lerneffekt für andere gleich null.

Hauptsächlich geht es bei der Softwareergonomie um folgende Punkte:

1. Wie sollen Fenster gestaltet werden
2. Aufbau von Menüstrukturen
3. Farb- bzw. Schriftwahl
4. ...

Die von mir genannten Punkte fallen in die von mir genannten Kategorien. Natürlich überschneiden sich diese Themenbereiche teilweise.