Solved

is this a bug in VB 5????

Posted on 1998-11-07
28
214 Views
Last Modified: 2010-04-30
Here is the basic idea of what my code does..when I run it, it highlights "DataReq = Right$(Totle, (Len(Totle) - 5))" and gives me error 13: Type Mismatch.  Sometimes the error handling works, and other times VB never even goes to the error handler and just gives me an error!
On Error goto Fixer
Dim DataReq as Integer
Restart:
*here is my code...next is the line which causes the error *ONLY if the string it's finding ISN'T a number.
*Let's say 'Totle' is "this is a test of my program"
DataReq = Right$(Totle, (Len(Totle) - 5))
Goto Restart

Fixer:*blah blah blah....exit sub

end sub

anyone have any ideas? I think it has something to do with the fact that I have dimensioned DataReq as integer..but then it should goto the error handler!! ???????
0
Comment
Question by:bomax
  • 14
  • 5
  • 5
  • +2
28 Comments
 
LVL 15

Expert Comment

by:ameba
ID: 1443777
Right click in your code window. Menu will show, select Toggle, Break on Unhandled errors.

0
 

Author Comment

by:bomax
ID: 1443778
I did that  but it STILL does the same thing.  This is really weird.
0
 

Author Comment

by:bomax
ID: 1443779
I did that  but it STILL does the same thing.  This is really weird.
0
 
LVL 15

Expert Comment

by:ameba
ID: 1443780
Are you sure you have option "Break on Unhandled errors", error handler, and it still pops error dialog?
0
 

Author Comment

by:bomax
ID: 1443781
I did that  but it STILL does the same thing.  This is really weird.
0
 

Author Comment

by:bomax
ID: 1443782
I am 100% sure.
0
 
LVL 15

Expert Comment

by:ameba
ID: 1443783
OK. Perhaps this is only with Type Mismatch errors. So, you must help vb.
DataReq = Right$(Totle, (Len(Totle) - 5))
replace with (if Datareq is integer):
DataReq = Val(Right$(Totle, (Len(Totle) - 5)))

0
 
LVL 15

Expert Comment

by:ameba
ID: 1443784
Oops, I didn't want to give answer,
You can completely avoid error with checking:
If IsNumeric(Right$(Totle, (Len(Totle) - 5))) Then

0
 
LVL 15

Expert Comment

by:ameba
ID: 1443785
I tested it. It is realy like you said.
this produces error dialog:
x = Right$(Totle, (Len(Totle) - 5))
but this does not:
x = (Right$(Totle, (Len(Totle) - 5)))

Funny! ()

0
 
LVL 15

Expert Comment

by:ameba
ID: 1443786
But, I don't think this is a bug. I think this is by design. They only wanted to warn us, that we are not explicitly converting string to integer.
So, we can add Val to convert it, check with IsNumeric, or use ()
0
 
LVL 12

Expert Comment

by:mark2150
ID: 1443787
You also need to execute a RESUME to clear error handler so additional errors can be trapped. All code execute after error flag is raised until RESUME is assumed to be in error handler and error handler CANNOT have errors.

M

0
 

Author Comment

by:bomax
ID: 1443788
Well I did some testing of my own.....I think that the problem is with the fact that I have no 'resume' statement.  that you all so much!!   thanks for your help ameba...but I dont really see those results in my own testing.  Mark - come and claim u're points!!!

THANK YOU ALL WHO HELPED ME!!  =)
0
 
LVL 12

Accepted Solution

by:
mark2150 earned 50 total points
ID: 1443789
Thanx!

0
 
LVL 15

Expert Comment

by:ameba
ID: 1443790
Hi, mark2150
Congratulations on your points, but bomax has: "Exit Sub" in his error handler. There is no need for RESUME

0
What Is Threat Intelligence?

Threat intelligence is often discussed, but rarely understood. Starting with a precise definition, along with clear business goals, is essential.

 
LVL 3

Expert Comment

by:vikiing
ID: 1443791
Every time an error is generated, its resolution remains as "pending" until a RESUME be executed, no matter which other instructions you execute (including Exit Sub).

The proper way to exit from an error-handling routine, is always thru RESUME statement.
0
 
LVL 15

Expert Comment

by:ameba
ID: 1443792
Hello, vikiing
Lets say you have error handler:

   On error goto CriticalError ' enable error handling
   ...
   Exit sub

CriticalError:
' since error is critical, I want to exit sub
' I always use exit sub, but what is the proper way, using resume
' ameba> Exit Sub
' vikiing>
0
 
LVL 3

Expert Comment

by:vikiing
ID: 1443793
Dear Ameba:

      Your code should read like this:

    On error Goto CriticalError
     . . .

Goodbye:
    Exit Sub

CriticalError:
     . . .
     Resume GoodBye

     End Sub

Each time an error is detected, an internal flag marks the error as "Pending of resolution". Thus, if another error appears under that condition, VB will take the know action (stopping the program under control of ITS OWN error handling routine).

RESUME is the only instruction that removes the flag; thus, when another error appears, your error handling routine will activate again.

0
 
LVL 1

Expert Comment

by:wford
ID: 1443794
you should use err.clear after you fix your error so that the error register is empty, and do as ameba said, use
Val to convert it, check with IsNumeric, or use () , or Cint()

the goto error should be used as a last resort, where you have no choice but to catch the error like this :)
0
 
LVL 15

Expert Comment

by:ameba
ID: 1443795
You really think additional label (Goodbye:) IS NECESSARY, even though there is no clean-up code (reseting mousepointer, clearing variables)?
"It is not nece... Don't you tell me what is nece! Of course it is not nece!" (from "High anxiety")
0
 
LVL 12

Expert Comment

by:mark2150
ID: 1443796
You *MUST* use RESUME to clear the error trap flag. ERR.CLEAR does *NOT* clear the internal state variable. It DOES remove the ERR.LINE/ERR.NUM values, but the internal state varible remains active until RESUME is executed.

There are several options on RESUME

RESUME          (no options - retry line that caused error)
RESUME NEXT (execution resumes at 1st line after error)
RESUME {target} (Execution resumes where you want.

Normally I code like:

On error Goto CriticalError
 . .

Exit Sub
' =========

CriticalError:
 . .
Resume GoodBye
Goodbye:

End Sub

This is really the only way to cleanly abort on an error.

An extra label in your code doesn't take up *ANY* resource so what is objection? The fact that it acts like a "GOTO" is inherent in the language and cannot be avoided. This is one of the reasons that GOTO will never completely die. While GOTO's are to be avoided whenever possible, this is one case where it is simply *NOT* possible to avoid it.

Vikiing is right. wford is wrong.

If you do NOT set a specific ON ERROR GOTO statement then the OS will handle the error and your program will *DIE* without doing any attempts at recovery. This is very annoying to the users as the program flames out, possibly leaving files open and losing data. So instead of "GOTO ERROR" being a "last resort" as WFORD suggests, it actually is your first line of defense.

One common error that programmers make is to assume what the error was without checking the Err.Num. This can occassionally lead to the program displaying an *erroneous* error message. Take the case of a file OPEN statement to a R/O device like a CD ROM or maybe a network directory without sufficient priveleges. The programmer may have only anticipated the cause of an error to be "Disk Full" so the program pops a "Disk Full" error when the LAN shows 387Gb of free space. This is root cause of many squirley error messages.

M
0
 
LVL 3

Expert Comment

by:vikiing
ID: 1443797
Dear Ameba:
    The label is mandatory, 'cause that's the only way to reach a point from a RESUME statement that transfers control outside error handling routine.

But, ¿what's the problem with it?. Some people think that GOTO's (or instructions like that) are bad words, and that a well-structured program must not have them.

Many times, the use of a GOTO (with good sense & judge) is the most elegant way to solve certain problems. Try to go outside a complex chained-IF structure, from the innest to the outest one. Of course, you can use a ton of flags; but ¿what about doing this?:
    If
         If
              If
                  If
                       If <certain condition> THEN OUTSIDE
                  end if
              end if
         end if
OUSTSIDE:
   end if

C'mon; that's the easiest way, withou endangering the marvelous structured way your program could be written out.
0
 
LVL 12

Expert Comment

by:mark2150
ID: 1443798
Yep. There are just some constructs that cry out for the *occassional* GOTO.

In reality the compiler will generate the occassional unconditional JMP (asm equiv of GOTO. In fact this happens every time you code a:

IF... THEN

ELSE

ENDIF

Without the implicit GOTO or JMP there is no way for the first case to reunite after the ENDIF.

M

0
 
LVL 15

Expert Comment

by:ameba
ID: 1443799
Ok. Additional label, Err.Clear, all this works, but Exit Sub/Property/Function in error handler is also correct, and shortest way to Exit after error. If you look at MS examples (e.g. Setup1.Vbp or Visdata.Vbp) you will not see unnecessary code and labels. I am not saying they are always correct, but you can check values in Err object yourself.
After Exit Sub, error is cleared.

Private Sub Form_Click()
   Call errie
   MsgBox Err.Description
End Sub

Sub errie()
    Dim x
    On Error GoTo e
    x = 1 / 0
    Exit Sub
e:
    Exit Sub
End Sub

The cases when err will not be cleared:
1. Using Raise Method
e:
   On error goto 0
   err.Raise vbObjectError+1001
End Sub

2. Not using error handler in errie procedure
. etc
0
 
LVL 15

Expert Comment

by:ameba
ID: 1443800
And I have nothing against GOTO!
0
 
LVL 15

Expert Comment

by:ameba
ID: 1443801
Discussion was: is RESUME necessary, hey
0
 
LVL 12

Expert Comment

by:mark2150
ID: 1443802
Omitting the RESUME *will* bite you.

Exit SUB is *NOT* going to clear it as ON ERRORS are *GLOBAL* in scope.

The example may not show it correctly. I've seen cases where failure to have a RESUME has caused all sorts of funnies even tho EXIT SUB has been used.

M
0
 
LVL 15

Expert Comment

by:ameba
ID: 1443803
Discussion was: is RESUME necessary, hey
0
 
LVL 15

Expert Comment

by:ameba
ID: 1443804
Sorry for repost,
Yes, on error is global.
We are not talking about this.
If we want to talk about this, you should suggest setting On Error Resume statement in error handler, or checking caller proc, or callers' caller error handling.
0

Featured Post

What Is Threat Intelligence?

Threat intelligence is often discussed, but rarely understood. Starting with a precise definition, along with clear business goals, is essential.

Join & Write a Comment

The debugging module of the VB 6 IDE can be accessed by way of the Debug menu item. That menu item can normally be found in the IDE's main menu line as shown in this picture.   There is also a companion Debug Toolbar that looks like the followin…
When trying to find the cause of a problem in VBA or VB6 it's often valuable to know what procedures were executed prior to the error. You can use the Call Stack for that but it is often inadequate because it may show procedures you aren't intereste…
Get people started with the process of using Access VBA to control Outlook using automation, Microsoft Access can control other applications. An example is the ability to programmatically talk to Microsoft Outlook. Using automation, an Access applic…
This lesson covers basic error handling code in Microsoft Excel using VBA. This is the first lesson in a 3-part series that uses code to loop through an Excel spreadsheet in VBA and then fix errors, taking advantage of error handling code. This l…

708 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

20 Experts available now in Live!

Get 1:1 Help Now