Resume On Error

abbes

hi,
gibt es die moeglichkeit bei einem fehler in einer methode mit dem naechsten schritt fortzufahren:

private void form_Load(object sender, System.EventArgs e)
{	
  try
  {
    this.setData();
  }
  catch(Exception ex)
  {
    if(ex is NullReferenceException)
    {
      // RESUME...
    }
  }
}

private void setData()
{
  test a = new test("XYZ");
  textbox1 = a.Bezeichnung;
  ...
  this.Text = "Programm";
  ...
}

kann hier z.b. a nicht instanziert werden, soll trotzdem noch der text gesetzt werden...

mfg abbes

Noodles

Anweisungen im finally Block werden immer ausgeführt, egal ob Exception oder nicht.

abbes

ja, aber was bringt denn der finally-block, wenn's im setData, welches im try-block aufgerufen wird, zu einem fehler kommt?
der sinn ist ja, dass mit dem naechsten schritt im setData fortgefahren wird/werden soll.

der hintergrund bei mir ist, dass ein objekt mehrere arrays aus verschiedenen anderen objekten enthaelt, die in mehreren listviews angezeigt werden sollen
wenn ein array null ist, weil's dafuer einfach keine werte gibt, wird eine
"NullReferenceException" geworfen.
ich koennte zwar jede foreach anweisung, mit der ich ein lv fuelle in einen try-catch-block einbetten - gibt aber halt je nach objekt ziemlich viel code...

Vorsicht: Wenn im finally-Block selber eine Exception fliegt, werden die restlichen Anweisungen dort drin auch nicht ausgeführt.

Und das ist definitiv nicht unwahrscheinlich. Im finally macht man oft Sachen wie Socket.close(), Stream.close(), ... und da kann schon mal ne IOException kommen.

Im Zweifelsfall um jedes Ding im finally nochmal ein try und nirgends vergessen! (Checked Exceptions lassen grüßen)
On Error Resume Next war mein beliebtester VB6-Hack. Zum Glück gibt's das nicht in C#.

ja, aber was bringt denn der finally-block, wenn's im setData, welches im try-block aufgerufen wird, zu einem fehler kommt?
der sinn ist ja, dass mit dem naechsten schritt im setData fortgefahren wird/werden soll.

Neinneinein. Überlege dir genau, wo welcher Fehler kommen darf und reagiere auf jede erwartete Situation entsprechend. Wenn eine angemessene Reaktion wirklich aus dem Fortfahren mit der nächsten Anweisung besteht, dann fang sie und mach nichts.
Das macht Arbeit, aber ist sauberer.

abbes

[quote="Optimizer"]
On Error Resume Next war mein beliebtester VB6-Hack....
[/quote]

jaja, das waren noch zeiten
ich find's aber eigentlich schade, das man sowas nicht (mehr) verwenden kann um
einen (erwarteten!) fehler abzufangen.

Der Grund ist doch klar. Mit On Error Resume Next fängst du auch unerwartete Fehler ab. Wenn du ne IOException erwartest und ein NullPointer kommt, denkst du dir nichts dabei, weil du es nicht mal mitkriegst.

abbes

nein, in vb6 wuerde ich so vorgehen:

Public Sub Test()

On Error GoTo ErrHandler
...
...
...
Exit Sub

ErrHandler:
  Select Case Err.Number
    Case 91
      Resume Next
    Case Else
      Err.Raise
  End Select

End Sub

wie du siehst wuerde auch hier nur bei einem nullpointer fortgefahren werden.

Inwiefern ist das Abfragen von dem Fehlercode dann besser als ein paar catch-Blöcke?
Der Vorteil bei Resume Next wäre ja gewesen, dass er gleich mit der nächsten Anweisung weitergemacht hätte, was er jetzt bei dem Code aber auch nicht tut.

Fehlerbehandlung über ein globales Fehlerobjekt ist sowieso Schrott. Es wird dir eh nichts anders übrig bleiben, als dich mit Exceptions anzufreunden. Die Fehlerbehandlung, der du gerade nachtrauerst, ist aus gutem Grund abgeschafft worden.

abbes

falls du dich jetztz auf den vb-code beziehst: der macht mit der naechsten anweisung weiter.

zu den exceptions: ich mag sie!! auf jeden fall!! ich fahre sogar voll darauf ab,
haben mir definitiv schon eingiges aerger an aufwand erspart...
ich frage mich halt nur ob es sinn macht 10, 15 try-bloecke untereinander zu schreiben wobei es in jedem nur zu dem selben fehler kommen kann;
bzw. ob dies auch anders zu loesen ist.