c# try ohne catch-inhalt?

[Falk (Gast)]

Hi,
ich möchte prüfen ob ein string der in einem objekt einer Tabelle landet 
eine Zahl ist.
wenn der string eine Zahl ist, so möchte ich das Obejt meiner Tabelle 
entsprechend markieren, ich hinterlege also die zusätzliche Information 
dass es ein Integer ist.
ist es keine Zahl, so wird das Datenformat string beibehalten, Es wird 
nichts gemacht!

Ich löse das in meiner Anwendung so:

Int32 i32Zahl;
try
{
  i32Zahl = Convert.ToInt32(Text);  // bei Text landen wir hier im catch!
  objektformat[cell] = Obj.Typ.Integer;  // Wert als Zahl markieren
}
catch
{
}

So, nun höre ich überall dass man keine unbehandelten catch-Blöcke haben 
soll. Aber ich verstehe nicht warum?
Wenn im oberen Beispiel der Text nicht nach int konvertiert werden kann, 
dann muss auch der Datentyp nicht geändert werden!
wieso also einen Inhalt (sprich "code"!!) beim catch hinschreiben!?

Ist das, was ich hier mache, wirklich so unschön?

[Peter II (Gast)]

Falk schrieb:
> wieso also einen Inhalt (sprich "code"!!) beim catch hinschreiben!?
> Ist das, was ich hier mache, wirklich so unschön?

ja ist es, wenn der code ein wenig länger wird, können auch mal andere 
Exceptions auftreten mit den man am anfang nicht gerechent hat. Dann 
such mal ewig nach so einen Fehler.

Und dieser code lässt sich mit tryParse eh lesbarer schreiben

http://msdn.microsoft.com/de-de/library/vstudio/f02979c7.aspx

[Falk (Gast)]

danke!
tryParse scheint hier wirklich besser zu sein!

[Urmel aus dem Eis (Gast)]

Exceptions sind wie der Name sagt Ausnahmen, bei dir ist es aber sogar 
vorgesehen also gerade keine Ausnahme, dass eine Tabelle auch 
Zeichenketten enthält.

[Uhu U. (uhu)]

Falk schrieb:
> So, nun höre ich überall dass man keine unbehandelten catch-Blöcke haben
> soll. Aber ich verstehe nicht warum?

Wenn es für das Wiederaufsetzen egal ist, was die Ursache für eine 
Ausnahme ist und diese Ausnahmen nicht abgeschaltet werden können, dann 
ist ein leerer catch-Block eine sinnvolle Lösung.

Zum Debug kann man solche Ausnahmen natürlich zu Diagnosezwecken 
abfangen.

Richtige Probleme kann man allerdings bekommen, wenn man, ungetesteten 
Code im try-Block ruft.

[Vermuter (Gast)]

Ich vermute tryParse wird intern genau dass machen was du in deinem try 
block hast und je nach dem ob die Funktion eine exception geworfen hat 
true oder false zurückgeben.

Gekapselt sie das natürlich schicker aus und ist wartbarer

[Peter II (Gast)]

Vermuter schrieb:
> Ich vermute tryParse wird intern genau dass machen was du in deinem try
> block hast und je nach dem ob die Funktion eine exception geworfen hat
> true oder false zurückgeben.

und warum soll es nicht andersrum sein? Bei dem convert wird intern ein 
TryParse aufgerufen und wenn das false liefert, dann wird eine exception 
geworfen.

[Vermuter (Gast)]

Weil die Methode Int32.TryParse in im .Net Framework 2.0 eingeführt 
wurde

Die Convert gab es vorher schon.

http://msdn.microsoft.com/de-de/library/vstudio/f02979c7(v=vs.80).aspx
http://msdn.microsoft.com/en-us/library/sf1aw27b(v=vs.80).aspx

[Arc N. (arc)]

Peter II schrieb:
> Vermuter schrieb:
>> Ich vermute tryParse wird intern genau dass machen was du in deinem try
>> block hast und je nach dem ob die Funktion eine exception geworfen hat
>> true oder false zurückgeben.
>
> und warum soll es nicht andersrum sein? Bei dem convert wird intern ein
> TryParse aufgerufen und wenn das false liefert, dann wird eine exception
> geworfen.

So ähnlich.
TryParse (und auch die entsprechenden Methoden in Convert und Int32) 
rufen Methoden aus der Number-Klasse auf (ParseInt32, TryParseInt32, 
usw.), die dort irgendwann bei ParseNumber landen...

http://referencesource.microsoft.com/netframework.aspx