Laden...

try catch errormessage

Erstellt von Bakunin vor 18 Jahren Letzter Beitrag vor 18 Jahren 3.528 Views
B
Bakunin Themenstarter:in
50 Beiträge seit 2005
vor 18 Jahren
try catch errormessage

Hi Leute,

ich habe ein grundlegendes Designproblem. Und zwar arbeite ich sehr gerne mit Try und Catch, da es so sehr leicht ist Fehler abzufangen. Aber Try und Catch ist meiner Meinung nach sehr sehr langsam. Darum sollte man (denke ich) alle Fehler die man ohne Try und Catch abfangen kann, vorher schon abfangen und als Rückgabewert einer Funktion bool wählen und True oder False zurückgeben, anstatt eine Exception zu werfen.

Dabei ergibt sich aber dass Designproblem (vl ist es ja gar kein Problem und so genau richtig), dass man nun in jeder Klasse einen string braucht indem die Errormessage steht.

zB:


	public class ConfigurationHandler{
		private string m_Error;
		
		public string Error{
			get{	return this.m_Error;	}
		}
		
		public bool writeConfiguration(string Path, object Configuration){
			try{
				using(TextWriter oWriter = new StreamWriter(Path)){
					XmlSerializer oSerial = new XmlSerializer(Configuration.GetType());
					oSerial.Serialize(oWriter, Configuration);
					return true;
				}
			}
			catch(System.Exception e){
				this.m_Error = e.Message;
				return false;
			}
		}
}

//Aufruf
		XMLConfiguration.ConfigurationHandler x = new XMLConfiguration.ConfigurationHandler();
		
		if(!x.writeConfiguration("fail", null)){
			Console.WriteLine(x.Error);
		}

So, was mich wie gesagt stört, ist dass in jeder Klasse nun ein Error string vorhanden sein muss, worin der Exception-Fehler gespeichert wird.
Da gibt es doch sicherlich bessere Designansätze....

lg
Bakunin

49.485 Beiträge seit 2005
vor 18 Jahren

Hallo Bakunin,

Da gibt es doch sicherlich bessere Designansätze....

ja, Exceptions zu verwenden. Jede Abweichtung davon ist eine Extrawurst, die zu nichts anderem kompatibel ist. Und da du es (vermutlich) nicht schaffen wirst, die Welt von deinem Designansatz zu überzeugen, verwende den Standard: Excpetions.

herbivore

B
Bakunin Themenstarter:in
50 Beiträge seit 2005
vor 18 Jahren

Also lieber Exceptions werfen...
na dann, tu ich sowieso lieber 😉

/edit
Und als Rückgabetyp in dem Fall void? Weil wenn eine Exception geworfen wird, dann verabschiedet man sich aus der Funktion oder?

Vielen Dank

B
Bakunin Themenstarter:in
50 Beiträge seit 2005
vor 18 Jahren

Also ich hoffe ich habe dich richtig verstanden.
Hier mein aktualisierter Code:


public void writeConfiguration(string Path, object Configuration){
	try{
		using(TextWriter oWriter = new StreamWriter(Path)){
			XmlSerializer oSerial = new XmlSerializer(Configuration.GetType());
			oSerial.Serialize(oWriter, Configuration);
		}
	}
	catch(System.Exception e){
		throw e;
	}
}

//Aufruf
try{
	this.oCHandler.writeConfiguration("/tmp/myconfig.xml", oConfig);
}
catch(System.Exception e){
	//Errorhandling
}

49.485 Beiträge seit 2005
vor 18 Jahren

Hallo Bakunin,

du kannst und solltest es noch kürzer machen, indem du das try/catch in writeConfiguration weglässt. Das ist ja u.a. das nützliche an Exceptions, dass man sie nur da ins Spiel bringen muss, wo man sie behandeln will. Dein Code mit dem "rethrow" hat zudem den Nachteil, dass man nicht mehr sieht, wo die Exception unrsprünglich entstanden ist. Stattdessen wird als Ursprungsort die Zeile von deinem throw e eingetragen.

herbivore

4.221 Beiträge seit 2005
vor 18 Jahren

Original von Bakunin

  
  catch(System.Exception e){  
  	throw e;  
  
  
Nur so am Rande:  
  
Statt throw e;   reicht auch ein einfaches throw (dann wird die letzte gecatchte Exception wieder geworfen.

Früher war ich unentschlossen, heute bin ich mir da nicht mehr so sicher...

B
Bakunin Themenstarter:in
50 Beiträge seit 2005
vor 18 Jahren

Ah ok, daran habe ich gar nicht gedacht. Vielen Dank
Und danke für den Tipp Programmierhans!

Bakunin

4.221 Beiträge seit 2005
vor 18 Jahren

Ein "Rethrow" (also ein throw ohne Parameter) macht nur in den wenigsten Fällen Sinn sondern erhöht nur die Laufzeit des Codes (es treten ja 2 Exceptions auf).... Einzig Sinn macht es wenn die erste catchende Komponente noch was tun muss (z.B: den Fehler loggen (sprich Low-Level-Log) bevor die Exception dem Aufrufer um die Ohren gehauen wird).

Früher war ich unentschlossen, heute bin ich mir da nicht mehr so sicher...

S
8.746 Beiträge seit 2005
vor 18 Jahren

Nachtrag: Die Verwendung von Execeptions im Code verlangsamt die Ausführungzeit überhaupt nicht. Nur das Fangen von geworfenen Exceptions (gerade der ersten wegen JIT) ist im Vergleich zu einem Returncodes tatsächlich deutlich langsamer. Da aber Exceptions wirklich als "Ausnahmen" verwendet werden sollten, ist das Performance-Argument nur in den allerseltensten Fällen maßgebend.

4.221 Beiträge seit 2005
vor 18 Jahren

Original von svenson
Nur das Fangen von geworfenen Exceptions (gerade der ersten wegen JIT) ist im Vergleich zu einem Returncodes tatsächlich deutlich langsamer.

Und genau dies hat er hier unnötigerweise gemacht... es wurde eine Exception gefangen um diese dann wieder zu werfen.

Früher war ich unentschlossen, heute bin ich mir da nicht mehr so sicher...

S
8.746 Beiträge seit 2005
vor 18 Jahren

Das macht allerdings nur Sinn, wenn man die Exception loggen möchte, oder was weiss ich damit anstellen.

4.221 Beiträge seit 2005
vor 18 Jahren

Original von svenson
Das macht allerdings nur Sinn, wenn man die Exception loggen möchte, oder was weiss ich damit anstellen.

Genau dies habe ich vorher ja beschrieben (wobei Du meinen Zwischenpost vermutlich gar nicht gesehen hast, da sich unsere Posts überschnitten haben)

Früher war ich unentschlossen, heute bin ich mir da nicht mehr so sicher...

49.485 Beiträge seit 2005
vor 18 Jahren

Hallo zusammen,

wollte noch anmerken, dass jeder "rethrow", egal ob mit oder ohne Parameter, zu dem von mir oben beschriebenen Effekt des "verfälschten" Ursprungs führt.

herbivore

D
155 Beiträge seit 2005
vor 18 Jahren

Hierzu würde ich auch noch gerne anmerken:

Ich denke ein "rethrow" macht auch Sinn, wenn man z.B. eine Klasse programmiert die mehrfach verwendet wird. Es ist so möglich, dass die "höheren" Prozeduren, Subs bzw. Voids die Exception behandeln. Je nachdem kann dann der Programmierer der Funktion damit weiter Arbeiten. (Er kann dann einschätzen den Grad des Fehlers und muss dann nicht zwangsweise eine Message anzeigen lassen.)