Why does this compile?

Hi guys,

First of all, I have to agree with Duh on his comment:

Quote:

---

what is the point of having types in the arguments of a function if they are not used to help the coder avoid passing incorrect things to functions before it is run

---

VB does compile the example Duh posted when you would think it obviously shouldnt, but there are reasons why it does compile.

VB 4.0 introduces the concept of "automatic type coercion". Apparently it makes code more efficient, but what it means is that variables of certain data types can automatically get converted to other types without you having to convert it explicitly. Integers to Booleans, Strings to Dates, Strings to Numbers, etc. There are rules that get followed by VB with these coercions.

Obviously this isnt going to be everyones preferred coding approach, but its built into the fabric of VB and thus needs to be maintained for eternity to allow backward compatibility.

Anyway, the fact of the matter is that assigning a string to a integer is considered "legal" by the compiler due to these coercion rules, i.e., the string "1234" can be coerced to the number 1234, but the string "abcd" cannot, so its not until the code is actually executed that it realises that the text "abcd" is not really a number, and it then becomes a runtime error and not a compiler error. So compiling your code into an executable is allowed, but when you run it, you get a type mismatch runtime error.

Make sense?

Its not very strong type casting, and I am not sure if I agree with the whole idea of it myself ... you have CStr() CInt() CLng() etc, if you want to convert your data types, and I dont like VB making assumptions for me ... but for others it probably makes life alot easier.

So there you have it ... you are all smarter now :D

Cheers,
Tinbum747

mine did give an error. I run all my programs using the START WITH FULL COMPILE option on. Maybe thats the difference, if it is off then it onlys picks up the error after the line has been encountered.

Start with full compile, should pick-up those typo's or errors...

I am a c/c++ programmer myself, and c/c++ compiles the .cpp/.h files each time you run the application (depending on your environment settings), therefor c/c++ will pick this up, but in vb, it only runs the app no, error checking...

Explicitly pressing ctrl+F5 will force VB to compile the code to native-code which at this point should pickup stuff like that ... :)

But Option Explicit, needs to be turned on, and the keywords ->
'Option Explicit', needs to be at the top of each .frm, .mdl or what ever file .... :)

Sometimes, this option is off, an then in turn, when putting this on, it does not insert the key word at the top....

:)

Hi again,

Choosing 'Start With Full Compile' (Ctrl+F5) will still only check against compilation errors, not runtime errors.

If you take the following example:

Code:

---

Option Explicit

Public Sub Test(i As Integer)

End Sub

Private Sub Form_Load()
 
  Test "hello"

End Sub

---

When you run this example, you get a type mismatch error when you run the code, but it is a runtime error (it asks you if you want to debug or end, because your code is now running).

Now try the following, add a button to the form, and move the function call to the button click event:

Code:

---

Option Explicit

Public Sub Test(i As Integer)

End Sub

Private Sub Command1_Click()
 
  Test "hello"

End Sub

---

Choose 'Start With Full Compile' (Ctrl+F5) ... the form loads OK. Click on the button and you get the type mismatch runtime error.

Also, if you choose the 'Make xxx.exe' option from the File menu to compile your code into an executable, it works without errors.

Sadly you cant rely on using the 'Start With Full Compile' option to trap all of these runtime type mismatch errors, due to those coercion rules.

Cheers,
Tinbum747