Jun 21, 2018

2095

Kaskadierung von Fehlermeldungen vermeiden

Hallo Forum,
nachfolgend ein stark vereinfachter Beispiel-Code, der in der Sub-Prozedur einen Fehler erzeugt.

Sub Main()
  Try
    Call Sub1()
  Catch
    MsgBox („Fehler in Main“)
  End Try
End Sub

Sub Sub1()
  Try
    Dim i as Integer = 1/0
  Catch
    MsgBox („Fehler in Sub1“)
  End Try
End Sub

Beim Starten der Main-Prozedur werden folgende Fehlermeldungen angezeigt:
„Fehler in Sub1“
„Fehler in Main“

Ist es möglich, dass die Main-Prozedur erkennen kann, dass in der Sub1 bereits eine Fehlermeldung erzeugt wurde, so dass nicht eine weitere Meldung angezeigt wird. Insbesondere bei verschachtelten Aufrufen ist das Ganze sonst für den Nutzer ziemlich lästig.

Vielen Dank im voraus,
Marco Born

Please also mark the comments that contributed to the solution of the article

Content-Key: 377750

Url: https://administrator.de/contentid/377750

Printed on: April 24, 2024 at 02:04 o'clock

12 Comments

Latest comment

Hi,
das ist VB.Net?
Ich bekomme bei mir die IDE gar nicht dazu, mir das "1/0" abzukaufen. Es wird gar nicht erst kompiliert.
Aber selbst wenn ich das durch eine

throw new exception

ersetze kommt nur die Meldung aus Sub1.
irgendwas machst Du in der Realität anders, als Du es hier schilderst.

E.

Moin,

das sieht eher nach VBA als nach VB.NET aus...

I.d.R. macht man das so, das man in den Sub()s innerhalb des Catches den lokalen Fehler behandelt und dann per throw (bzw. err.raise in VBA) den Fehler "nach oben" an den aufrufenden Code zurückgibt. Dort wird dann der komplette Stacktrace ausgegeben.

lg,
Slainte

Hallo,
das mit dem 1/0 war ja auch nur ein Beispiel. Mein Code sieht natürlich um einiges komplexer aus. Hier mal ein konkretes Beispiel für den Catch-Bereich:

		Catch ex As Exception
			Using xmObjMboLogger As New ClsMboLoggingKlasse
				Dim mObjMboLogger As ILogging = DirectCast(xmObjMboLogger, ILogging)

				gStrMboMessage = ex.Message
				If StrComp(gStrMboMessage, "See inner exception(s) for details.", vbTextCompare) = 0 Then  
					gStrMboMessage = ex.InnerException.Message
				End If
				gStrMboMessage &= vbLf & ex.StackTrace
				mObjMboLogger.PubMboLogging(Me.GetType().Name & "." & Reflection.MethodBase.GetCurrentMethod().Name.ToString, "Absturz", gStrMboMessage)  
				MsgBox(gStrMboMessage, MsgBoxStyle.Exclamation, ex.Source)
				Throw
			End Using
		End Try

Ich bin mir halt nur nicht sicher, wie ich dort abfangen kann, wenn in einer Sub-Prozedur ein Bug auftritt, so dass die Fehlermeldungen nicht alle nacheinander angezeigt werden.

Viele Grüße,
Marco Born

so dass die Fehlermeldungen nicht alle nacheinander angezeigt werden.

Werden sie auch nicht. Darauf will ich doch hinaus. Da passiert dann in der Sub aber außerhalb des Try-Catch noch ein anderer Fehler. Lass Dir doch mit

msgbox ex.tostring

den Stack anzeigen. Da bekomst Du dann sogar die Codezeile geliefert, in welcher die Exception ausgelöst wird.

Doch, die Fehlermeldungen werden in jeder Prozedur angezeigt. In Code-Zeile 12 meines letzten Posts wird die MsgBox aufgerufen. Ich möchte zwar, dass der Nutzer einen Hinweis erhält, dass ein Fehler aufgetreten ist (möglichst auch mit Angabe der Prozedur und der Codezeile), aber halt nur einen Hinweis und nicht für jede Prozedur einen weiteren.

Ich weiß nicht, was Du da genau machst, dafür ist Dein Code-Ausschnitt zu kurz.
Aber bei mir liefert folgendes Bsp. genau eine Meldung:

 Sub Main()
    Try
      Call Sub1()
    Catch ex As Exception
      MsgBox(ex.ToString, MsgBoxStyle.Exclamation, ex.Source)
    End Try
  End Sub

  Sub Sub1()
    Try
      Dim SB As Text.StringBuilder
      SB.AppendLine("Hallo Welt!")  
    Catch ex As Exception
      MsgBox(ex.ToString, MsgBoxStyle.Exclamation, ex.Source)
    End Try
  End Sub

Ich glaube, ich habe jetzt den "Fehler" gefunden. In meinen Prozeduren wird am Ende immer nach der MsgBox ein Throw ausgeführt. Das ist bei Dir im Code nicht mit drin. Lasse ich Deinen Code durchlaufen, erhalte ich auch nur 1 Meldung; mit Throw erhalte ich die mehrfachen Meldungen.
Liege ich mit meiner Vermutung richtig, dass ich einfach die Throws überall entfernen muss?

Ja, Zeile 12. Das habe ich übersehen,, sonst hätte ich es genannt. Dieses "Throw" bewirkt, dass der Fehlerstack "weitergegeben" wird. Sprich, die Ausnahmen werden "nach oben" weitergereicht, also auch dem aktuellen Try-Catch-Block raus. Da in der Sub1 kein weiteres Try-Catch "drumherum ist", ist das "höhere" das aus der Sub Main.

Liege ich mit meiner Vermutung richtig, dass ich einfach die Throws überall entfernen muss?

Das kommt darauf an, was Du haben willst.
Wenn Du willst, dass die Behandlung der Ausnahme mit den Aktionen in der "Sub1" erledigt sein soll, dann darf da kein Throw rein. Wenn Du aber willst, dass in der Sub1 zwar auf die Ausnahme reagiert wird aber dann trotzdem noch an die "höhere" Sub gemeldet werden soll, dann musst es drin lassen oder Du löst statt dessen eine neue, eigene Exception aus.

Im Catch-Block mache ich nichts, was den Fehler bearbeitet. Der ist in allen Prozeduren gleich. Es soll dem Nutzer eine Fehlermeldung angezeigt werden, die Fehlermeldung in ein Logfile schreiben und dann das fehlerhafte Makro abbrechen. Die Nutzer können eh nichts am Code ändern und melden sich dann bei mir. Von daher ist es am sinnvollsten, überall das Throw zu entfernen. Vielen Dank für die Hilfe...

Und was ist das anderes als "die Behandlung der Ausnahme"?

Ich versuche halt nicht weiter, im Code den Typ der Exception herauszubekommen oder irgendwelche Fehlerbehandlungsmaßnahmen einzuleiten.

German solved Question Visual Studio Development

Hotly discussed

Check of ZFW Firewallgleixnerd - 5 Comments

Wireguard VPN on UDM Pro behind Fritzbox - Handshake did not completejstricker - 3 Comments

How to set up and configure a Linux GRE tunnelAlexWisha - 3 Comments