By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
425,705 Members | 1,852 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 425,705 IT Pros & Developers. It's quick & easy.

Module name identification in an error message

P: n/a
I am trying to dynamically populate the module name in the error
message.
Currently I populate a variable with hardcoded text:
strModuleName = "cmdFlushWorkTables_Click"

Per my code below, is there a way to populate strModulename
dynamically so that all I would need for the error message is the
message line itself? Is there some API call I can make that will
disclose the current module running so that when the error is raised,
that modulename would dynamically show up in my error message? If
there is a code sample for this, I would appreciate the assistance.

<begin code>
Private Sub cmdFlushWorkTables_Click()
On Error GoTo Err1

Dim blnReturn As Boolean
RunSQLReturn ("Delete * from tblCurrentMonthData")

Exit1:
Exit Sub

Err1:
strModuleName = "cmdFlushWorkTables_Click"
MsgBox Err.Number & ". " & Err.Description, vbExclamation,
gblPgmName & "-Error in " & strModuleName
Resume Exit1
End Sub
<end code>

Thanks.
Jan 2 '08 #1
Share this Question
Share on Google+
4 Replies


P: n/a
On Jan 2, 11:57 am, rlntemp-...@yahoo.com wrote:
I am trying to dynamically populate the module name in the error
message.
Currently I populate a variable with hardcoded text:
strModuleName = "cmdFlushWorkTables_Click"

Per my code below, is there a way to populate strModulename
dynamically so that all I would need for the error message is the
message line itself? Is there some API call I can make that will
disclose the current module running so that when the error is raised,
that modulename would dynamically show up in my error message? If
there is a code sample for this, I would appreciate the assistance.

<begin code>
Private Sub cmdFlushWorkTables_Click()
On Error GoTo Err1

Dim blnReturn As Boolean
RunSQLReturn ("Delete * from tblCurrentMonthData")

Exit1:
Exit Sub

Err1:
strModuleName = "cmdFlushWorkTables_Click"
MsgBox Err.Number & ". " & Err.Description, vbExclamation,
gblPgmName & "-Error in " & strModuleName
Resume Exit1
End Sub
<end code>

Thanks.
TTBOMK no one who has discovered a way to do this has yet shared his
or her knowledge.

I disagree with many or most when I say that very few VBA procedures
require any Error Handling Code. I use Error Handling Code only when I
set a state or handle, such as turning off screen updating with ECHO
or opening low level DOS files with Open, that I want to be sure is un-
set or released when there is an error

Error Handling Code is like a Class Module; both are often useless,
but we think they make us look good!
Jan 2 '08 #2

P: n/a
>>Error Handling Code is like a Class Module; both are often useless,<<
I use error handling quite liberally, only because I had a problem
occur that bit me bad on a production issue.
Sub1 called Sub2, which called Sub3 (trust me....the code for each was
very lengthy and -had- to be separated out)
There was an error message thrown in Sub1. After digging endlessly
for quite some time, the error actually occurred down inside Sub3. If
I had proper error handling in all three modules, the message from
Sub3 would have been displayed had I included proper error handling
there....live and learn.
>>TTBOMK<< ...have never seen this abbrev before. ??
Jan 8 '08 #3

P: n/a
>>>TTBOMK<< ...have never seen this abbrev before. ??

[T]o [T]he [b]est [O]f [M]y [K]nowledge
Jan 8 '08 #4

P: n/a
On Jan 8, 10:34 am, rlntemp-...@yahoo.com wrote:
>Error Handling Code is like a Class Module; both are often useless,<<

I use error handling quite liberally, only because I had a problem
occur that bit me bad on a production issue.
Sub1 called Sub2, which called Sub3 (trust me....the code for each was
very lengthy and -had- to be separated out)
There was an error message thrown in Sub1. After digging endlessly
for quite some time, the error actually occurred down inside Sub3. If
I had proper error handling in all three modules, the message from
Sub3 would have been displayed had I included proper error handling
there....live and learn.
>TTBOMK<< ...have never seen this abbrev before. ??

Sub sub1()
Debug.Print 1 / 0
End Sub

Sub sub2()
sub1
End Sub

Sub sub3()
sub2
End Sub

Call Sub3
Where does debug point?
To Debug.Print 1 / 0
Jan 8 '08 #5

This discussion thread is closed

Replies have been disabled for this discussion.