I just got an bug report from a customer and found the problem was something
like this:

Dim c as new ADODB.Command
set c = GetNewConnection ' function that returns a new sqlserver connection

The last line should have read "set c.activeConnection = GetNewConnection".
Now I'm going to have to do a new build and go through all the hassle of a
release (there's quite a few steps to this now). Undoubtedly this got out
due to human error however c# or vb.net wouldn't have even let this line of
code compile because it knows straight off that a connection object cannot
be set into a command object. It's amazing how many similar errors it picks
up like this while working. Many of those errors would be picked up fairly
quickly but some will get through.

Michael

Methinks the DotNotHead doth protest too much.
[..]

"Michael C" <nospam> wrote in message
news:a964
> I just got an bug report from a customer and found the problem was
> something
> like this:
>
> Dim c as new ADODB.Command
> set c = GetNewConnection ' function that returns a new sqlserver
> connection
>
> The last line should have read "set c.activeConnection =
> GetNewConnection".
> Now I'm going to have to do a new build and go through all the hassle of a
> release (there's quite a few steps to this now). Undoubtedly this got out
> due to human error however c# or vb.net wouldn't have even let this line
> of
> code compile because it knows straight off that a connection object cannot
> be set into a command object. It's amazing how many similar errors it
> picks
> up like this while working. Many of those errors would be picked up fairly
> quickly but some will get through.


You can't blame this on VB. GetNewConnection is apparently not returning a
reference to an ADODB.Connection object. It it were, you'd have gotten a
Type Mismatch error (I tested it to be sure). So, it's YOUR fault and ONLY
your fault (or whoever the programmer was). There's no excuse for this bug
not to have gotten discovered during testing.

As to "Wish I was using .net", well....use it then and quit your bellyaching
about VB6. <g> Other than ranting, what was the purpose of your message?

"MikeD" <nobody> wrote in message
news:3360
> You can't blame this on VB. GetNewConnection is apparently not returning
> a reference to an ADODB.Connection object.

It is definately returning a connection object.

> It it were, you'd have gotten a Type Mismatch error (I tested it to be
> sure).

Yes but unfortunately the customer got the error not the programmer or
tester.

> So, it's YOUR fault and ONLY your fault (or whoever the programmer was).

It most definately is.

> There's no excuse for this bug not to have gotten discovered during
> testing.

Possibly but the point is if we were using .net the error would have been
picked up immediately, it wouldn't have been left open to human error and
there would be zero chance of it getting to the customer. If programmers
make this same mistake enough times eventually one will get out.

This isn't the first time this has happened. We had some code that used a
Field object, somehow the order of references got mixed up and an
ADODB.Field all of a sudden became an ActiveReports.Field. Parts of the app
that were changed had been tested but we got the problem in an unchanged
part of the app. Basically VB compiled code that it should have know would
never run. Not only would dotnet have noticed the type mismatch but the
issue would never have arised because you are forced to specify the library
(namespace in dotnet) you are using.

> As to "Wish I was using .net", well....use it then and quit your
> bellyaching about VB6. <g>

When management let me move over then I'll stop complaining but I can't see
that happening in a hurry.

> Other than ranting, what was the purpose of your message?

This stricter type casting is probably the single best feature in dotnet, it
is worth highlighting to those that haven't made the move yet. It might
sound like a minor change but you realise it is a huge advantage once you've
used it for a while. You also get errors if a function doesn't return a
value or if you fail to define the type for a variable. Plus you can't
specify an enum value on its own without prefixing it with the enum name, so
enums can't get mixed up even if they have really common names.

Michael

Can you post some code samples, I too cannot get this to compile. Having a
function return a connection, and trying to set that to a command object
gives me a type mismatch at runtime. I am interested in learning under what
circumstances this can occur so I can avoid it if I come across it.

Lance

"Michael C" <nospam> wrote in message
news:1192
"MikeD" <nobody> wrote in message
news:3360
> You can't blame this on VB. GetNewConnection is apparently not returning
> a reference to an ADODB.Connection object.

It is definately returning a connection object.

> It it were, you'd have gotten a Type Mismatch error (I tested it to be
> sure).

Yes but unfortunately the customer got the error not the programmer or
tester.

> So, it's YOUR fault and ONLY your fault (or whoever the programmer was).

It most definately is.

> There's no excuse for this bug not to have gotten discovered during
> testing.

Possibly but the point is if we were using .net the error would have been
picked up immediately, it wouldn't have been left open to human error and
there would be zero chance of it getting to the customer. If programmers
make this same mistake enough times eventually one will get out.

This isn't the first time this has happened. We had some code that used a
Field object, somehow the order of references got mixed up and an
ADODB.Field all of a sudden became an ActiveReports.Field. Parts of the app
that were changed had been tested but we got the problem in an unchanged
part of the app. Basically VB compiled code that it should have know would
never run. Not only would dotnet have noticed the type mismatch but the
issue would never have arised because you are forced to specify the library
(namespace in dotnet) you are using.

> As to "Wish I was using .net", well....use it then and quit your
> bellyaching about VB6. <g>

When management let me move over then I'll stop complaining but I can't see
that happening in a hurry.

> Other than ranting, what was the purpose of your message?

This stricter type casting is probably the single best feature in dotnet, it
is worth highlighting to those that haven't made the move yet. It might
sound like a minor change but you realise it is a huge advantage once you've
used it for a while. You also get errors if a function doesn't return a
value or if you fail to define the type for a variable. Plus you can't
specify an enum value on its own without prefixing it with the enum name, so
enums can't get mixed up even if they have really common names.

Michael

"Lance Wynn" <LanceWynn> wrote in message
news:a916
> Can you post some code samples, I too cannot get this to compile. Having
> a
> function return a connection, and trying to set that to a command object
> gives me a type mismatch at runtime. I am interested in learning under
> what
> circumstances this can occur so I can avoid it if I come across it.

That is what it is meant to do. The point is you get it at runtime, not at
compile time like it should.

Michael

Oh,
Then I have to agree with MikeD, that's just the way the language is. In
..NET, or any language for that matter you'll find a number of runtime errors
that for whatever reason the compiler won't catch. It has nothing to do
with the language, or the compiler. There are a number of instances in VB
where you wouldn't want the compiler to raise an error at compile time if
there were a potential type mismatch. If you don't catch something in
testing, then you don't catch it, that's how every language works.

Lance


"Michael C" <nospam> wrote in message
news:a344
"Lance Wynn" <LanceWynn> wrote in message
news:a916
> Can you post some code samples, I too cannot get this to compile. Having
> a
> function return a connection, and trying to set that to a command object
> gives me a type mismatch at runtime. I am interested in learning under
> what
> circumstances this can occur so I can avoid it if I come across it.

That is what it is meant to do. The point is you get it at runtime, not at
compile time like it should.

Michael

"Lance Wynn" <LanceWynn> wrote in message
news:2704
> Oh,
> Then I have to agree with MikeD, that's just the way the language is. In
> .NET, or any language for that matter you'll find a number of runtime
> errors
> that for whatever reason the compiler won't catch. It has nothing to do
> with the language, or the compiler.

But VB is a leaky sieve in this regard missing a *lot* of errors that it
should have caught. You want the language to do as much as possible catching
every error it can, leaving the less obvious stuff up to the programmer or
tester.

Dotnet on the other hand is very tight and the one and only situation I can
think of is a foreach statement, which doesn't check the type until runtime.

> There are a number of instances in VB
> where you wouldn't want the compiler to raise an error at compile time if
> there were a potential type mismatch.

No, you never want this. A language should always give you an error for any
implicit type conversion that could cause an error or loss of data, and
force you to explicitly do a conversion.

Michael

You say you tested the changes but it affected a different part of the
program, if that was the case you did not test the program properly!

For commercial software a proper testing regime will have:
Testers who are NOT the developers.
At every build testing jobs should be raised to test any changes and any
potential ramification.
Before releasing a build ALL previous tests must be retested. (Regression
testing - Very important).
A really comprehensive system of keeping details and results from each test.

The language, environment, operating system, colour of wallpaper etc are all
unimportant, if you don't test properly you will release duff code from time
to time.
As as example, where I work there are more people employed to do testing
than programmers generating code to be tested, this is the way it should be
and since we've had this regime no seriously faulty software has gone out of
our door.
It's expensive for sure, but in the long term having a reputation for
software which always works is well worth the spend (it is of course not my
money, so easy for me to say). Also never having customers contact us with
"did you know if you do this..." is satisfactory in itself.
I don't know what volumes and unit costs your product moves. Our product is
low volume, high cost, a different model may not generate enough money to
justify full time testing staff in which case you will have to make do with
whoever you have, but it is crucial that a programmer should NEVER test
their own code.

Best Regards
Dave O.

"Michael C" <nospam> wrote in message
news:a208
[..]

"Michael C" <nospam> wrote in message
news:OcDNSpZNGHA.964
> Wish I was using .net

I wish you were too. Maybe then you'd stop trolling this newsgroup.

Except for late binding, I always want the compiler to raise an error if
there is a type mismatch. VB.Net (VB 2005) has an additional "OPTION"
statement, "Option Strict On/Off" that tells the compiler to flag all type
casting errors. "Option Strict Off" defaults to VB 6's method of allowing
the compile to pass right on through without catching the error. "Option
Strict On" catches these very common errors at compile time (actually while
you're editing since the syntactical pass of the compiler runs in background
all the time). Yes, this can be a pain in the butt when first switching
from VB 6 to VB 2005, but it's worth the pain in the form of cleaner code.

Mike Ober.

"Lance Wynn" <LanceWynn> wrote in message
news:2704
[..]

"Michael C" <nospam> wrote in message
news:a208
> "Lance Wynn" <LanceWynn> wrote in message
> news:2704
> > Oh,
> > Then I have to agree with MikeD, that's just the way the language is.
In
> > .NET, or any language for that matter you'll find a number of runtime
> > errors
> > that for whatever reason the compiler won't catch. It has nothing to do
> > with the language, or the compiler.
>
> But VB is a leaky sieve in this regard missing a *lot* of errors that it
> should have caught. You want the language to do as much as possible
catching
> every error it can, leaving the less obvious stuff up to the programmer or
> tester.
>

I concur. I have worked with weakly typed languages and strongly typed
languages and definitely prefer strongly typed languages. Having the
compiler catch as many errors as possible is far better than catching them
at runtime. Remember it's always cheaper (and less embarrasing) to fix a
problem before release than after release.

> Dotnet on the other hand is very tight and the one and only situation I
can
> think of is a foreach statement, which doesn't check the type until
runtime.

VB 2005 catches type casting errors in for each ... next statements.

>
> > There are a number of instances in VB
> > where you wouldn't want the compiler to raise an error at compile time
if
> > there were a potential type mismatch.
>
> No, you never want this. A language should always give you an error for
any
> implicit type conversion that could cause an error or loss of data, and
> force you to explicitly do a conversion.
>
> Michael
>

I just wish MS hadn't thrown out the baby with the bathwater when
modernizing VB 6. As may people in this NG have correctly pointed out, MS
made a lot of changes to the VB language that break a lot of existing code.
I suspect many of these changes were unnecessary, despite the protestations
of the MS VB development team.

Mike Ober.

"Michael D. Ober" <obermd.@.alum.mit.edu.nospam> wrote in message
news:1760
>
> I just wish MS hadn't thrown out the baby with the bathwater when
> modernizing VB 6. As may people in this NG have correctly pointed out, MS
> made a lot of changes to the VB language that break a lot of existing
> code.
> I suspect many of these changes were unnecessary, despite the
> protestations
> of the MS VB development team.
>
> Mike Ober.

Actually, it's the MS VB dev team that put us in this mess. They're the ones
that did and want to be able to make future changes on a whim (depending on
the flavor of their starbucks that day)

Will VB ever be standardized?
"C# has been submitted and approved by the ECMA, will Visual Basic ever be
submitted?"
"Well, never say never, but there are no current plans to submit Visual
Basic to a standards body."
http://www.panopticoncentral.net/arc.../30/10911.aspx

....and, if you look at the language spec for VB2005, you'll see that the
language they used leaves this "I changed it because I can" rule intact.

"The information contained in this document represents the current view of
Microsoft Corporation on the issues discussed as of the date of publication.
Because Microsoft must respond to changing market conditions, it should not
be interpreted to be a commitment on the part of Microsoft, and Microsoft
cannot guarantee the accuracy of any information presented after the date of
publication.
This Language Specification is for informational purposes only. MICROSOFT
MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN
THIS DOCUMENT"

The main problem with the VB team is.... they don't use VB. Never have,
never will. (I'm sure someone'll pop in and say "you're wrong, look at this
snip I wrote") Besides, they suffer from "all new team members" where one
team gets the boot and another takes its place and couldn't care less what
the previous team was doing. Too busy trying to be a Rock Star I guess....

NET Rock Star: Paul Vick
http://www.findarticles.com/p/articl...iff124655/pg_2

"Dave" <nobody> wrote in message
news:3988
> I don't know what volumes and unit costs your product moves. Our product
> is low volume, high cost, a different model may not generate enough money
> to justify full time testing staff in which case you will have to make do
> with whoever you have, but it is crucial that a programmer should NEVER
> test their own code.

That is part of the problem in that either the money is not there for
dedicated testers or management don't want to spend that money (I suspect
the second :-). However, even if we did have good testing it is possible the
original problem I stated would have got through because like a lot of code
it only gets run in special circumstances. The point is with dot net there
would be a zero chance of that bug getting through.

Michael

"Michael D. Ober" <obermd.@.alum.mit.edu.nospam> wrote in message
news:3728
>
> Except for late binding, I always want the compiler to raise an error if
> there is a type mismatch. VB.Net (VB 2005) has an additional "OPTION"
> statement, "Option Strict On/Off" that tells the compiler to flag all type
> casting errors. "Option Strict Off" defaults to VB 6's method of allowing
> the compile to pass right on through without catching the error. "Option
> Strict On" catches these very common errors at compile time (actually
> while
> you're editing since the syntactical pass of the compiler runs in
> background
> all the time). Yes, this can be a pain in the butt when first switching
> from VB 6 to VB 2005, but it's worth the pain in the form of cleaner code.

As far as I'm concerned it shouldn't have been an option, or should have
been the other way around ("Option Slack" perhaps :-). You can't have
anything but strict type casting in C#.

Michael