Connecting Tech Pros Worldwide Help | Site Map

Module name identification in an error message

 
LinkBack Thread Tools Search this Thread
  #1  
Old January 2nd, 2008, 04:05 PM
rlntemp-gng@yahoo.com
Guest
 
Posts: n/a
Default Module name identification in an error message

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.

  #2  
Old January 2nd, 2008, 05:35 PM
lyle
Guest
 
Posts: n/a
Default Re: Module name identification in an error message

On Jan 2, 11:57 am, rlntemp-...@yahoo.com wrote:
Quote:
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!


  #3  
Old January 8th, 2008, 02:35 PM
rlntemp-gng@yahoo.com
Guest
 
Posts: n/a
Default Re: Module name identification in an error message

Quote:
Quote:
>>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.
Quote:
Quote:
>>TTBOMK<< ...have never seen this abbrev before. ??
  #4  
Old January 8th, 2008, 03:45 PM
Stuart McCall
Guest
 
Posts: n/a
Default Re: Module name identification in an error message

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

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


  #5  
Old January 8th, 2008, 03:55 PM
lyle
Guest
 
Posts: n/a
Default Re: Module name identification in an error message

On Jan 8, 10:34 am, rlntemp-...@yahoo.com wrote:
Quote:
Quote:
Quote:
>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.
>
Quote:
Quote:
>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
 

Bookmarks

Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On

Popular Articles

What is Bytes?

We are a network of experts and professionals in IT and software development that help one another with answers to tough questions and share insights. Get the best answers to your questions from over 220,840 network members.