On Error is not trapping divide by zero 1

[erstout]

I have the following function - it's not too difficult, as you can see...but the condition "length = 0" WILL NOT TRAP!
This is VB 5.0...anybody have any freakin' ideas?
I tried it in baseline code first and then tried breaking it out as a function - no dice either way.

Private Function SetFactor(length As Integer)
On Error GoTo FactorError
SetFactor = 32767 / length
Exit Function

FactorError:
MsgBox "Bad CRN length"
End Function

 

[ponerse]

It's working in VB6. Don't know why it wouldn't be working for you.

 

[erstout]

and what's even worse, I have error traps all over the place in other subroutines in the same form that apparently are working.

I'm wondering if somehow using the class property rollatt.rolllength is resetting the error trap?

 

[DrJavaJoe]

Goto tools -> options menu and on the general tab see if Break on all error is chacked. It should be break in Class module.

 

[erstout]

Thanks - that takes care of it indeed. Does this mean my conjecture was right about the Class object resetting the error trap?

 

[erstout]

And if I had built the executable, would it still have had the same behaviour (i.e. not trapping the error) or would the compiled code have trapped properly?

 

[DrJavaJoe]

If it was compiled the error handler would have worked. As far as the class module resetting the error trap, I have no idea.

 

[TheBigViking]

Instead of relying on error trapping, do your own error checking for example "If length = 0 then exit sub"

The problem with error traps, which in this instance is so big, is that you can hide errors. All you are looking for is divide by zero. Why must you trap for all possible errors when only looking for one?

If you want to you can then raise an error for the calling procedure??? err.raise Report error to user for example
The Big Viking

 

[CajunCenturion]

Personally, I prefer the "Break on Unhandled Errors" option.

I also agree with Viking, to a point, that some error prevention can be done in code, such as checking denominator values before division, rather than relying on error handling. I prefer prevention to recovery if possible.

Not all errors can be prevented, so robust error handling is still a must. Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[CassandraR]

Hi Erstout:

A couple of suggestions:

1. Make sure each code module has "Option Explicit" at the start of it.

2. Define the return type for your Functions. In your code sample, you left the definition as

Private Function SetFactor(length as Integer)

whereas good programming practice would have used

Private Function SetFactor(length as Integer) As Single

or something similar. Your definition forces VB to treat SetFactor as a variant.

Cassie

 

[ponerse]

Good ideas by Cassie. Coding that way also makes .NET translation/conversion much easier down the road.

 

[strongm]

Following on from ponerse's post, for those considering making the transition from VB6 to VB.NEt the following link may be of interest:

http://msdn.microsoft.com/vbasic/downloads/codeadvisor/default.asp

 

[TheBigViking]

Going back to the days when I used to write in QBasic the only time an error trap was really required was when the control actually left the program. For example, opening a file. Most other error checking used to be done in code.

The practice of putting On Error Resume Next at the top of almost each sub, is in fact, bad coding. Its is my opinion that people use error traps so much these days to hide bad coding practices and techniques. If a person relied on you own coding to do error checking, that person would know that by the time that the product was released, after thorough testing, that all the coding bugs would have been fixed. Error traps let bad code go into production, and I believe that this is the reason why there is so much bad, bad sofware out there.

Maybe my background in assembler programming has influenced my opinion. There were no such things as error traps. You code had to work! My point still remains, Error trapping hides bad code. As stated before, one of the only places where error trapping is perfectly acceptable, is when the actual control leaves the boundaries of the code. Trap for errors that might occur then. The rest should be up to good code and coding practices and techniques.

Opinionated, Yours sincerely,
The Big Viking

 

[erstout]

I appreciate all the information and I'm glad it's given people a chance to discuss the proper use of onerror traps - but from my perspective, the problem I had is resolved: a debug option for breakpoints of which I was unaware.
On a final note before I abandon this thread, I concur with the big viking; except to point out that a) sometimes you are dealing with legacy code and onerror can be a very useful debugging assist, b) sometimes you are dealing with poorly defined or controlled input from a third party and c) I was very glad to find that the problem wasn't a fundamental change in Basic that had disabled divide-by-zero error trapping.