Dynamically Get Sub Name

[John Walker]

Hi, Is there a way to dynamically get the name of the current Sub?
In my code below in the exception "catch" i write the name of the Sub to the
error log so that i will know where there error happened, but since i reuse
this code in other Subs i sometimes forget to change the name of the Sub. is
there a way to get it dynamically?
Also, is there a way to write out the line number where the error happened
so you can pinpoint exactly where the error occurred?
And if anyone has any suggestions for any other useful information which i
can write to the error log, i'd appreciate it.
Thanks, John

Private Sub subGetTruckerCodes( _
ByRef argDS As DataSet _
)

Try

If sqlConnect.State = ConnectionState.Closed Then
sqlConnect.Open()
End If
sqlConnect.ChangeDatabase("AccountManage")
Dim dad As New SqlDataAdapter("spGetProfileTruckerCodes", sqlConnect)
dad.SelectCommand.CommandType = CommandType.StoredProcedure
dad.SelectCommand.CommandTimeout = 120

Dim ds As New DataSet
dad.Fill(ds)

Catch ex As Exception

Log.Error("subGetTruckerCodes")
Log.Error(ex.Message)

End Try

End Sub

 

[Armin Zingler]

Hi, Is there a way to dynamically get the name of the current Sub?
In my code below in the exception "catch" i write the name of the
Sub to the error log so that i will know where there error happened,
but since i reuse this code in other Subs i sometimes forget to
change the name of the Sub. is there a way to get it dynamically?

Dim sf As New StackFrame(True)

Then call sf.GetMethod to get a MethodBase object. It has a Name
property and others.

See also sf.GetFileLineNumber, sf.GetFileName etc. Only available if you
pass True to the constructor and if you also deploy the symbol file
(pdb).

Line number of exception:
- see ex.stacktrace

- Or:

Dim st As New StackTrace(ex, True)
Dim Frame = st.GetFrame(0)
'now Frame.GetFileLinenumber returns the line number

(maybe there's a shorter way but I didn't find one).



Armin

 

[John Walker]

Great, thanks Armin, i'll give it a shot.

Dim sf As New StackFrame(True)

Then call sf.GetMethod to get a MethodBase object. It has a Name
property and others.

See also sf.GetFileLineNumber, sf.GetFileName etc. Only available if you
pass True to the constructor and if you also deploy the symbol file
(pdb).

Line number of exception:
- see ex.stacktrace

- Or:

Dim st As New StackTrace(ex, True)
Dim Frame = st.GetFrame(0)
'now Frame.GetFileLinenumber returns the line number

(maybe there's a shorter way but I didn't find one).



Armin

 

[Phill W.]

Hi, Is there a way to dynamically get the name of the current Sub?

Yes. Several, actually.

In my code below in the exception "catch" i write the name of the Sub to the
error log so that i will know where there error happened, but since i reuse
this code in other Subs i sometimes forget to change the name of the Sub. is
there a way to get it dynamically?

(IMHO) Never, never log /just/ ex.Message. Show it to the user by all
means, but *always* log the whole thing - ex.ToString().

That way, you automagically get not just the /current/ method's name but
that of /every/ method in the call stack at the time the Exception
occurred - and all without /any/ effort on your part.

Also, is there a way to write out the line number where the error happened
so you can pinpoint exactly where the error occurred?

For that, you have to ship the ".pdb" file along with the application's
..exe. With both of these in place, line numbers will be added into the
Exception StackTrace (again, automagically).

And if anyone has any suggestions for any other useful information which i
can write to the error log, i'd appreciate it.

If you need the method name for tracing purposes (for, say, logging the
entry and exit points for every function as the program runs), then you
can use

System.Reflection.MethodBase.GetCurrentMethod().Name

HTH,
Phill W.

 

[Mythran]

John Walker wrote:

For that, you have to ship the ".pdb" file along with the application's
.exe. With both of these in place, line numbers will be added into the
Exception StackTrace (again, automagically).

When you ship the PDB file, aren't you doing a Debug build (in order to
generate the PDB) and not a Release build, therefore you'll have the extra
overhead and debugging code in the executable as well? Are Release and
Debug builds identical except that the PDB file gets generated in a Debug
build?

Mythran

 

[Phill W.]

When you ship the PDB file, aren't you doing a Debug build (in order to
generate the PDB) and not a Release build, therefore you'll have the
extra overhead and debugging code in the executable as well?

I may well be wrong about this, but I don't think so.
You /can/ have the pdb file created even from within the Release
configuration.

Are Release and Debug builds identical except that the PDB file
gets generated in a Debug build?

I don't think so, no.

Debug builds often include additional stuff that is simply omitted from
the Release version, like conditionally-compiled code dependent on the
DEBUG flag:

#If DEBUG Then
' Code omitted from Release build
#End If

Having said that, you'd probably need someone who's been /inside/ the
Redmond Reality Distortion Zone to confirm or deny this. I doubt any
mere Mortal is allowed to know what goes on inside the compiler.

Regards,
Phill W.

 

[Jack Jackson]

When you ship the PDB file, aren't you doing a Debug build (in order to
generate the PDB) and not a Release build, therefore you'll have the extra
overhead and debugging code in the executable as well? Are Release and
Debug builds identical except that the PDB file gets generated in a Debug
build?

No. For example typically a Debug build doesn't do any compiler
optimization.

If you look at the Compile section of the project properties and click
on Advanced Compile Options, you can control compilation options for
any kind of build, including Release ("Generate debug info" controls
how much debugging information is included).