C#: ErrorCode-> String Ausgabe

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

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