Protecting against type mismatch errors

[Howard Kaikow]

I'm doing a VB 6 project in which I am trying to protect against type
mismatch errors.
Is the process any different in VB .NET?

Here's what I'm doing in VB 6.

I have an ActiveX DLL.
The class has stuff initialized by calling a sub SetClass that wants some
Word specific objects passed-in.
If the user mistakingly uses the wrong object, say, uses an Excel object
instead of a Word object, a nasty type mismatch error is generated when I
try to use the variable.

To avoid this error, I set all the args to, ugh!, Variant, and then use
TypeName to test the arg and then use On Error to catch any error when first
using the object.

Would the same methodology work in VB .NET by using Object instead of
Variant.?
According to the VB .NET in a Nutshell book (page 560), TypeName in VB .NET
has some behaviorial differences from TypeName in VB 6.

So, how wouldone make code "type mismatch proof" in VB .NET?

 

[Armin Zingler]

I'm doing a VB 6 project in which I am trying to protect against
type mismatch errors.
Is the process any different in VB .NET?

Yes, a lot!

First, the VB6 compiler doesn't check the types with objects types! You
could pass a Form object to a procedure expecting a CommandButton. The check
is done at runtime. VB.Net does this at compile time according to the type
information. VB6 supports default items without arguments. If the
passed object doesn't support the interface according to the declaration,
the runtime checks whether the object has a default property that might fit.
If it doesn't either, a runtime error occurs. Due to the lack of default
properties w/o arguments in (VB).Net, this is also excluded.

Second, in VB.Net you have Option Strict. No implicit unintended type
conversions are done. If you want to convert, convert.

Here's what I'm doing in VB 6.

I have an ActiveX DLL.
The class has stuff initialized by calling a sub SetClass that wants
some Word specific objects passed-in.
If the user mistakingly uses the wrong object, say, uses an Excel
object instead of a Word object, a nasty type mismatch error is
generated when I try to use the variable.

To avoid this error, I set all the args to, ugh!, Variant, and then
use TypeName to test the arg and then use On Error to catch any
error when first using the object.

Would the same methodology work in VB .NET by using Object instead
of Variant.?

As Object is the base class for everything, declaring something as Object
wouldn't prevent you from passing the wrong object type, but if you declared
the specific type, the check is done at compile time. Always.

According to the VB .NET in a Nutshell book (page 560), TypeName in
VB .NET has some behaviorial differences from TypeName in VB 6.

So, how wouldone make code "type mismatch proof" in VB .NET?

If TypeOf bla Is ... then

- just like in VB6. I mean, how to check the type. More important is to
declare the variable as the specific type.




Armin

 

[Howard Kaikow]

First, the VB6 compiler doesn't check the types with objects types! You
could pass a Form object to a procedure expecting a CommandButton. The check
is done at runtime.

Runtime was the subject of my question.
Compile time is not the issue.

Second, in VB.Net you have Option Strict. No implicit unintended type
conversions are done. If you want to convert, convert.

Option Strict does not solve the problem.

The goal is to avoid a run-time error.
Since the code is being called from a Word template, the Option Strict in
the DLL doesn't prevent a run-time error.

If TypeOf bla Is ... then

- just like in VB6. I mean, how to check the type. More important is to
declare the variable as the specific type.

According to VB .NET in a Nutshell (page 560), TypeName does not work the
same as in VB 6.
A number of exceptions are cited. For example, the following is alleged,
I've not tried to confirm:

Dim strVar as String

TypeName(strVar) in VB 6 returns "String", in VB .NET returns "Nothing".

The reason stated by the book is that VB.NET "strings are reference types
and reference types are implemented as objects".

 

[Herfried K. Wagner [MVP]]

According to VB .NET in a Nutshell (page 560), TypeName does not work the
same as in VB 6.
A number of exceptions are cited. For example, the following is alleged,
I've not tried to confirm:

Dim strVar as String

TypeName(strVar) in VB 6 returns "String", in VB .NET returns "Nothing".

ACK, 'TypeName' will return 'Nothing' for the 'String' type. You may want
to use 'strVar.GetType().Name' instead.

 

[Armin Zingler]

Runtime was the subject of my question.
Compile time is not the issue.


Option Strict does not solve the problem.

The goal is to avoid a run-time error.
Since the code is being called from a Word template, the Option
Strict in the DLL doesn't prevent a run-time error.

I think, resolving the problem at compile time helps to avoid runtime
errors. That's why I mainly referred to strict typing.

According to VB .NET in a Nutshell (page 560), TypeName does not
work the same as in VB 6.
A number of exceptions are cited. For example, the following is
alleged, I've not tried to confirm:

I thought that Typename is not so important for the reason given above. I
don't know the book, so I can't make a comment on this. I also can only
lookup the changes since VB6 in the docs. In addition, I don't know anything
about integrating a .Net DLL in a Word template.

Dim strVar as String

TypeName(strVar) in VB 6 returns "String", in VB .NET returns
"Nothing".

The reason stated by the book is that VB.NET "strings are reference
types and reference types are implemented as objects".

Concerning this specific case I can only say that you now also have to check
whether the string is Nothing. I don't know how extensive your checks are
and have to be. What other concerns are there about Typename?
As the documentation says: "Compare the result of the TypeName function with
the result in the Visual Basic 6.0 to determine if they are the same, and
modify your code if necessary."
Wherever possible, I prefer "TypeOf Is" to Typename to avoid runtime errors
due to misspelled type name literals.



Armin

 

[Armin Zingler]

ACK, 'TypeName' will return 'Nothing' for the 'String' type. You
may want to use 'strVar.GetType().Name' instead.

Leads to a NullReferenceException if nothing - as you know.

Armin

 

[Howard Kaikow]

I think, resolving the problem at compile time helps to avoid runtime
errors. That's why I mainly referred to strict typing.

Yes, but the code would be in a DLL and the class would be called from Word
VBA, so there's no possibility of controlling the calling code. When Office
is fully .NET-ized, maybe this will change.

In the case in question, I am making it (nearly) impossible to use the DLL,
other than by calling it from a Word template that I am supplying.

Even tho the VBA project in that template will be password protected, which
really is not secure anyway, I want to protect the DLL from somebody passing
in incorrect types.