Get Calling Function Info

[Li Pang]

Hi,

I built many classes to be used. One function can call one or more other
functions. If any of these functions have an error I add the error
description into a log file. My problem is to identify all calling functions,
ie, I want to get the full path of called function: f1 calls f2, and f2 calls
f3, then f3 gets an error, I want to get f1, f2 names. Is that a way to do it?
Thanks in advance

[Tim Patrick]

See the online help in Visual Studio for the System.Diagnostics.StackTrace
class. There is a warning with that class that it doesn't provide as detailed
information when running a program compiled as "Release."

If you are using Visual Basic 2005, you can also access the following property,
which returns a string with the entire stack trace.

My.Application.Info.StackTrace

-----
Tim Patrick
Start-to-Finish Visual Basic 2005

Hi,

I built many classes to be used. One function can call one or more
other functions. If any of these functions have an error I add the
error description into a log file. My problem is to identify all
calling functions, ie, I want to get the full path of called function:
f1 calls f2, and f2 calls f3, then f3 gets an error, I want to get f1,
f2 names. Is that a way to do it? Thanks in advance

[Phill W.]

Li Pang wrote:

I want to get the full path of called function: f1 calls f2, and f2 calls
f3, then f3 gets an error
Is that a way to do it?

It's all wrapped up in the Exception class.

Try
CallFunctionThatFails()

Catch ex As Exception

LogToFile( ex.ToString() )
' or extract the .Message and .StackTrace properties

End Try

It doesn't matter how many levels down into your code you go; the
Exception will contain the complete Stack, all the way down. Usually.

HTH,
Phill W.

[Miro]

So is it practice to do a Try Catch - prior to every function / procedure
call ?

M.

"Phill W." <p-.-a-.-w-a-r-d@o-p-e-n-.-a-c-.-u-kwrote in message
news:ei**********@south.jnrs.ja.net...

Li Pang wrote:

>I want to get the full path of called function: f1 calls f2, and f2 calls
f3, then f3 gets an error Is that a way to do it?

It's all wrapped up in the Exception class.

Try
CallFunctionThatFails()

Catch ex As Exception

LogToFile( ex.ToString() )
' or extract the .Message and .StackTrace properties

End Try

It doesn't matter how many levels down into your code you go; the
Exception will contain the complete Stack, all the way down. Usually.

HTH,
Phill W.

[Yuichiro Ochifuji]

Hi,

As long as I think, it is possible by writing Try-Catch in all procedures
and using Throw.
But, this is troublesome?(^^)

sample

Public Class Form1

Dim r As New System.Random()

Private Sub testA()
Try
Dim i As Integer

i = r.Next(3)

Dim j As Integer
j = 5 / i
testA()
Catch ex As Exception
Dim st As New System.Diagnostics.StackTrace(ex)

Throw New Exception(ex.Message & vbCrLf & st.ToString, ex)
End Try
End Sub

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
Try
testA()
Catch ex As Exception
MsgBox(ex.Message)
End Try
Debug.WriteLine("END")

End Sub
End Class

[Phill W.]

Miro wrote:

So is it practice to do a Try Catch - prior to every function / procedure
call ?

No. Definitely not.

You /only/ add Catch blocks when you can do something *useful* with the
Exception if happens, as in

Sub ReloadConfiguration()
Try

' [re-]read options from file
Dim sr As New StreamReader( "file" )
. . .
sr.Close()

Catch ex As FileNotFoundException

' [Re-]Apply /default/ options here

End Try
End Sub

Catching and rethrowing an Exception in every code routine is pointless,
redundant and just slows the code down.

Logging the exception /only/ counts as "useful" if your code is
providing a [central] service for a [remote] client. The logged version
is useful to you in diagnosing the problem, but probably not to your
clients. They /might/ want to get an Exception back (re-Throw it), or
you may ahve to "translate" it into something useful to them (e.g. an
error flag in the result returned by a WebService).

HTH,
Phill W.