Module name identification in an error message

Module name identification in an error message

am 02.01.2008 17:57:32 von rlntemp-gng

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.


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


Thanks.

Re: Module name identification in an error message

am 02.01.2008 19:28:58 von lyle

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.
>
>
> 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
>
>
> 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!

Re: Module name identification in an error message

am 08.01.2008 16:34:56 von rlntemp-gng

>>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. ??

Re: Module name identification in an error message

am 08.01.2008 17:38:17 von Stuart McCall

>>>TTBOMK<< ...have never seen this abbrev before. ??

[T]o [T]he [B]est [O]f [M]y [K]nowledge

Re: Module name identification in an error message

am 08.01.2008 17:52:35 von lyle

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