Comment On Some Basic Error Handling

Oh the PAIN, the PAIN!

Damn when is a programming genius going to come up with a simple, easy function to tell if a number IsNumeric()?

And on another note...

12345.6 is a 7-character number, but when you convert it to a long, it turns into 12345. Excellent programming work. This guy isn't even worthy of a "brillant".

Let's see, random Hungarian naming scheme, MsgBoxes in a function that should probably just return true or false, and a dumb re-invention of IsNumeric. That's about all I see. We must be running out of really good WTFs?

 

Manni:

12345.6 is a 7-character number, but when you convert it to a long, it turns into 12345. Excellent programming work. This guy isn't even worthy of a "brillant".

Sorry, numOrd isn't being used anywhere. Its only purpose is to raise an error if the input can't be converted to a Long. So the user input of 12345.6 wouldn't be converted to 12345, but this function would still return True.

 

Assuming this is VB6, this may not be that big of a WTF.  You could use isnumeric instead of the cheesey on error goto but that will validate numbers with decimals as well.

I always hated having to use error handling to determine whether or not a key was in a collection.  Talk about a language design WTF.  But I see this as something similar.

Am I missing the real WTF here?

Ah, the wizard is right.  It will validate a decimal anyway.

A Wizard A True Star:

Manni:

12345.6 is a 7-character number, but when you convert it to a long, it turns into 12345. Excellent programming work. This guy isn't even worthy of a "brillant".

Sorry, numOrd isn't being used anywhere. Its only purpose is to raise an error if the input can't be converted to a Long. So the user input of 12345.6 wouldn't be converted to 12345, but this function would still return True.

 

My point is that he first checks that the "number" contains 7 characters. I'm therefore assuming he's looking for a 7-digit number. 12345.6 will pass all of his criteria, and won't be a valid 7-digit number. I have a word for that, and it's spelled W-T-F.

numOrd = xOrdNum



Can you just assign a string to a long like that?

A Wizard A True Star:

Let's see, random Hungarian naming scheme, MsgBoxes in a function that should probably just return true or false, and a dumb re-invention of IsNumeric. That's about all I see. We must be running out of really good WTFs?

Hey, they can't all be Therac-25.

JohnO:

Ah, the wizard is right.  It will validate a decimal anyway.

I just had to try this. Not only will it do the conversion, but it will convert 12345.6 to 12346, not 12345. It appears that VB6 takes the liberty of rounding your number for you when assigning it to an integer. I even tried:

      numOrd = CInt(xOrdNum)

but numOrd still came out to 12346.

Just another dumb VB programmer. Many more seen, many more to come. They should forbid this dumb language.

A Wizard A True Star:

...MsgBoxes in a function that should probably just return true or false...

You expect a good MVC model from a VB programmer?

don:

numOrd = xOrdNum



Can you just assign a string to a long like that?

Sadly, yes. VB assumes you want the path of least resistance.

Is it just me, or would any 7 char string pass the checks? ie, abcdefg
order 'number'.  The length is checked, but never the actual
characters.  Or am I missing something?

A Wizard A True Star:

Let's see, random Hungarian naming scheme, MsgBoxes in a function that should probably just return true or false, and a dumb re-invention of IsNumeric. That's about all I see. We must be running out of really good WTFs?

 

Come on now, this isn't that bad for VB.  It's very easy to understand what is going on, and for the most part it works.  Besides, when it is done, they'll probably query a db for that order number, and if it's not valid the user will just get an error message or empty results or something.

Given that this is VB, I'd say this is hardly a WTF at all.

oi.

Anonymous:

Just another dumb VB programmer. Many more seen, many more to come. They should forbid this dumb language.

Look to the carpenter, not the tools. (That said, a sharp saw does make the work easier -- if you know how to use it.)

Anonymous:

Anonymous:

Just another dumb VB programmer. Many more seen, many more to come. They should forbid this dumb language.

Look to the carpenter, not the tools. (That said, a sharp saw does make the work easier -- if you know how to use it.)

It is a rare carpenter that deploys termites in everything he does.

-123456

But maybe the system allows negative order numbers, for orders entered before the system existed. And maybe it regards the above to be a 7-digit number. Make your own rules, I say.

Gotta love the error messages. "...a seven (7) digit Order Number." Apparently the programmer thought the user might not be sure what "seven" means. How user friendly. And then "Order # must be numeric." What's the "Order-Pound"? "Order-Hash"? "Order-Sharp"?

Oh, the order number must be numeric. And, let me guess, the order date must be a date. This is so helpful.

And "122308A" is too a numeric. See? It's got numbers.

What's so hard about coding the text box to ignore characters outside of 0-9?

--RA

 

Int(xOrdNum) would return 12345

HAK:

Is it just me, or would any 7 char string pass the checks? ie, abcdefg order 'number'.  The length is checked, but never the actual characters.  Or am I missing something?

In VB6, you can assign a string value to a numeric variable and the runtime will try to convert it. This is tried with the line:

   numOrd = xOrdNum

if this conversion throws an exception then the function returns false, so the characters of the string are being checked.

HAK:

Is it just me, or would any 7 char string pass the checks? ie, abcdefg order 'number'.  The length is checked, but never the actual characters.  Or am I missing something?

VB's runtime engine does casting without you having to tell it to. If you put a string as the left operand and a number as the right, VB automagically converts the number to a string.

In this case, it's doing the opposite. Convert the string to a number. If the string is not numeric, it will generate a run-time error, which will be caught by the abomination known as "On Error Goto". If no error occurred, the function exits with a return value of True, otherwise it goes to the errorhandler which sets the return value to False.

Abandon all common sense, ye who enter.

limelight:

HAK:

Is it just me, or would
any 7 char string pass the checks? ie, abcdefg order 'number'. 
The length is checked, but never the actual characters.  Or am I
missing something?

In VB6, you can assign a string value to a numeric variable and the runtime will try to convert it. This is tried with the line:

   numOrd = xOrdNum

if this conversion throws an exception then the function returns false, so the characters of the string are being checked.

Thank you .... haven't used VB6 at all.

And by the love of all things good and kind, the guy who wrote this code should be punished.

A Wizard A True Star:

Hey, they can't all be Therac-25.

Indeed, it's been a while (not once?) since we've seen an example of an ad hoc multithreading OS in the hands of a programmer who cannot tell shared variables are bad 8-)

I'm sure there are a lot of "great" WTF examples of multithreaded applications. I'll see if I can find something really juicy from one I had to work with in the past (basically it was (according to the manufacturer) a preemptive real-time operating system; the problem was that it would not preempt, nor were there any real-time guarantees...)

Manni:

Damn when is a programming genius going to come up with a simple, easy function to tell if a number IsNumeric()?

And on another note...

12345.6 is a 7-character number, but when you convert it to a long, it turns into 12345. Excellent programming work. This guy isn't even worthy of a "brillant".

Using IsNumeric() would be just as bad a "WTF" as trying to convert it to long.  Remember, IsNumeric() is *not* the same as Is EveryCharacterANumberFrom0to9().

The easiest way to validate this would be to use a simple LIKE expression:

Code LIKE "#######"

if that returns TRUE, it is a 7-digit number.

VB supports regex in some strange way, doesn't it?





Like, "^\d{7}$"





You know.











That actually looks kind of sexy. A little bit like swearing.





why the ^\d{7}$ do I have to validate 7 numbers?

Hey, I just found out that this forum chokes if you try to write down the JS shorthand for a regex.

It was fun. Let's try it again.

/foo[n|o]/

Hm, not quite, it seems.

I apologize for my triple post. One cannot edit.

Manni:

My point is that he first checks that the
"number" contains 7 characters. I'm therefore assuming he's looking for
a 7-digit number. 12345.6 will pass all of his criteria, and won't be a
valid 7-digit number. I have a word for that, and
it's spelled W-T-F.

I would call it a bug. Such things happen. Think of all the bugs that make software unsafe.

IMO it takes a lot more to make a WTF.

RevMike:

A Wizard A True Star:

...MsgBoxes in
a function that should probably just return true or false...

You expect a good MVC model from a VB programmer?

Some years ago, I had the job to translate VB code (from an Access
application) into PLSQL. It happened to be very large and complex
calculations that should be put into the database as stored procedures.
Can you imagine my face when I found - deep within a function of ~1500
lines of code - a MsgBox call?

A Wizard A True Star:

random Hungarian naming scheme

I see that a lot. I like to call it Mungarian Notation.

limelight:

JohnO:

Ah, the wizard is right.  It will validate a decimal anyway.

I just had to try this. Not only will it do the conversion, but it will convert 12345.6 to 12346, not 12345. It appears that VB6 takes the liberty of rounding your number for you when assigning it to an integer. I even tried:

      numOrd = CInt(xOrdNum)

but numOrd still came out to 12346.

It get worse.  VB6 uses symmetric rounding.  That means when the amount being rounded is exactly one-half of the unit, it will round towards an even digit.  17.5 is rounded to 18, and 2.5 is rounded to 2.  Symmetric rounding is not a bad thing, as it helps reduce rounding bias, but the VB6 docs do not state what sort of rounding is used, so you can get surprised.

Try calculating 17.5\2.5 (integer division) for some fun.

Sincerely,

Gene Wirchenko

Anyway, the one way would have been an explict check that xOrdNum = CStr(CInt(xOrdNum)) which would deal with any rounding.   You'd also have to check that it was in the correct numeric range as well.

Of course, what if the order number had to be seven digits but could have leading zeros?  If so, things get more complicated.

Honestly, in that situation, I'd give up with the brain-deadedness of VB6 and write my own function that just checked every character was in the string "0123456789" and verify there was exactly 7 characters.  And, no, VB6 doesn't have regular expressions.

Shannon:

Anyway, the one way would have been an explict check that xOrdNum = CStr(CInt(xOrdNum)) which would deal with any rounding.   You'd also have to check that it was in the correct numeric range as well.

Of course, what if the order number had to be seven digits but could have leading zeros?  If so, things get more complicated.

Honestly, in that situation, I'd give up with the brain-deadedness of VB6 and write my own function that just checked every character was in the string "0123456789" and verify there was exactly 7 characters.  And, no, VB6 doesn't have regular expressions.

Problem #1: CInt() can only handle numbers between -32,000 and +32,000 (roughly). Since these are supposed to be 7-digit numbers, I'd suggest using CLng(). But yeah, you have the right idea.

Problem #2: You can create a RegEx object in VB, it's kinda slow but it will work. Alternatively, there is a built-in operator called "Like" which would fit the bill nicely. Check out Jeff S's post above, it's probably the fastest and simplest solution in VB.

Lt's see....my order number was...

-4.0e+0

I like to order early ;-)

It seems like people here are breaking down into two distinct camps-- those who have dealt with VB6 before, and those who have not. To the former, the response is, "yeah? If you think that's bad...", to the latter, "MY EYES, etc, etc."

It's bad, sure, but it uses the idiom of VB (which, I think, is brutish and clumsy). You'd never do this is a strongly typed language, or if you knew more about VB. But from a beginning level (or even from the viewpoint of someone who was forced to learn VB for time-crunched project), it's pretty mundane.

So, yeah. I've seen far, far, far worse (like referencing form controls on hidden, but still living, forms on the other side of the app like they are global variables). Also, I've seen world VB.NET code, which I would love to post, were it not for my fear that my co-workers are reading this site, too.

 

I know what you mean about bad VB.Net code. You take a pinch of incompetant VB6 coders, an upgrade to VB.Net (because its "better" - well it is - but the best reason they can give you is "the autocomplete thingy is better") stir and swallow.

You end up with essentially VB6 code which has been forced to compile under VB.Net with judicious typecasting and general mangling.

Oh - be fair - programmers never write validation error messages like
that - they are always provided by some UI designer, and the QA
engineer screams when the error message, no matter how inane doesn't
match what was in the spec.



A programmer's error message is either much much more detailed, or non-existant. We all know that.

Anonymous:

I know what you mean about bad VB.Net code. You take a pinch of incompetant VB6 coders, an upgrade to VB.Net (because its "better" - well it is - but the best reason they can give you is "the autocomplete thingy is better") stir and swallow.

You end up with essentially VB6 code which has been forced to compile under VB.Net with judicious typecasting and general mangling.

The one thing that is differentiates VB.NET from C# is the horrible ability to do this turn Option explicit and strict off, after which VB.NET can resemble mangled spaghetti.

You will in this case end up with VB6 code forced to compile under VB.NET with uncertain typecasting and consistent mangling

Gene Wirchenko:

limelight:

JohnO:

Ah, the wizard is right.  It will validate a decimal
anyway.

I just had to try this. Not only will it do the conversion,
but it will convert 12345.6 to 12346, not 12345. It appears that VB6
takes the liberty of rounding your number for you when assigning it to
an integer. I even tried:

      numOrd = CInt(xOrdNum)

but numOrd still came out to 12346.

It get worse. 
VB6 uses symmetric rounding.  That means when the amount being
rounded is exactly one-half of the unit, it will round towards an even
digit.  17.5 is rounded to 18, and 2.5 is rounded to 2. 
Symmetric rounding is not a bad thing, as it helps reduce rounding
bias, but the VB6 docs do not state what sort of rounding is used, so
you can get surprised.

Try calculating 17.5\2.5 (integer division) for some fun.

Sincerely,

Gene Wirchenko

from the Type conversion functions help page...



When the fractional part is exactly 0.5, CInt and CLng always
round it to the nearest even number. For example, 0.5 rounds to 0, and 1.5
rounds to 2. CInt and CLng differ from the Fix and
Int functions, which truncate, rather than round, the fractional part of
a number. Also, Fix and Int always return a value of the same type
as is passed in.



Geeze, and many of you are critical of so many others.  CInt is
doing exactly as designed.  If you want to truncate use Int.

Anonymous:

Gene Wirchenko:

limelight:

JohnO:

Ah, the wizard is right.  It will validate a decimal
anyway.

I just had to try this. Not only will it do the conversion,
but it will convert 12345.6 to 12346, not 12345. It appears that VB6
takes the liberty of rounding your number for you when assigning it to
an integer. I even tried:

      numOrd = CInt(xOrdNum)

but numOrd still came out to 12346.

It get worse. 
VB6 uses symmetric rounding.  That means when the amount being
rounded is exactly one-half of the unit, it will round towards an even
digit.  17.5 is rounded to 18, and 2.5 is rounded to 2. 
Symmetric rounding is not a bad thing, as it helps reduce rounding
bias, but the VB6 docs do not state what sort of rounding is used, so
you can get surprised.

Try calculating 17.5\2.5 (integer division) for some fun.

Sincerely,

Gene Wirchenko

from the Type conversion functions help page...



When the fractional part is exactly 0.5, CInt and CLng always
round it to the nearest even number. For example, 0.5 rounds to 0, and 1.5
rounds to 2. CInt and CLng differ from the Fix and
Int functions, which truncate, rather than round, the fractional part of
a number. Also, Fix and Int always return a value of the same type
as is passed in.



Geeze, and many of you are critical of so many others.  CInt is
doing exactly as designed.  If you want to truncate use Int.

I guess you missed the point entirely. It's the design that is in question. Symmetric rounding is bullocks, whether by design or otherwise.

Oh by the way,defending something because it is by design amounts to nothing. Bad design is still bad design.

Ahhh yes, VB "programmers". That's why I created these, and wear mine with pride. [:D]

http://www.cafepress.com/radioactivecode

Coding, I think you mean.

Anonymous:

Coding, I think you mean.

No, I mean code.

I'd rather be watching TV than run in a marathon.

I'd rather be watching TV than running in a marathon.

I like the prior, not the latter. [:D]

If it's not 100% grammatically, I don't know. But the numerous people that have seen it have not made that comment. Must not be too bad. Besides, I just prefer it the way it is. [:)]

<I'd rather be watching TV than run in a marathon.>

That should be: "I'd rather watch TV than run in a marathon."

<I'd rather be watching TV than running in a marathon.>

This is correct.

I admit it's a minor infraction of the rules. At least you said "than" instead of "then". ;)

Anonymous:

That should be: "I'd rather watch TV than run in a marathon."

This is correct.

I admit it's a minor infraction of the rules. At least you said "than" instead of "then". ;)

Usually I'm quite good at not breaking such rules. Except
the times where I'm publicly pulled up on such matters by the grammar police. :$

BTW I checked this with Word's spell and grammar checker prior to posting and it seems fine. :)

Oh well, I still like the other one. I can live with a minor infraction.

b1xml2:

I guess you missed the point entirely. It's the design that is in question. Symmetric rounding is bullocks, whether by design or otherwise.

Oh by the way,defending something because it is by design amounts to nothing. Bad design is still bad design.

Symmetric rounding (or bankers ~) was introduced to decrease the statistical error. It's important where the rounding affects the value significantly, e.g. in banks.

If you round in scientific calculations, you'll coose the rounding to be below the noise level, so you don't need to mind the error. It's some magnitudes smaller than the normal rounding effect. If you round to cent, you'll have much more 0.5 ¢ cases, and it accumulates very fast.

So the WTF is that ........ Oh I get it, some twat was dumb enough to have learned VB6 thats the true WTF isnt it? (Now where is my prize?)

Public Function VerifyOrdNum(xOrdNum As String) As Boolean

  If xOrdNum Like "#######" Then

    VerifyOrdNum = True

  Else

    MsgBox "Order # must be seven (7) digits long.", , strErrTitle

    VerifyOrdNum = False

  End If

End Function

Ha. And some people think programmers are geeks! I'll never work that one out.

A Wizard A True Star:

Let's see, random Hungarian naming scheme, MsgBoxes in a function
that should probably just return true or false, and a dumb re-invention
of IsNumeric. That's about all I see. We must be running out of really
good WTFs?

It not at all like IsNumeric, which is not as useful as people think