Compile time v runtime exceptions

Question

Please see the code below:

Public Class Student

End Class

Public Class Undergraduate
    Inherits Student

    Public Sub Test(ByVal o As Object, ByVal s As Student)
        o.Hello() 'Line 8
        s.Hello() 'Line 9

    End Sub
End Class

Line 8 throws an exception at runtime i.e. missing member exception. Line 9 produces a compile time error i.e. Hello is not a member of Student. Why doesn't line 8 throw a compile time exception.

This behaviour is only observable with `Option Strict Off` and it should be noted that this is *not* the recommended setting. In fact, it should be considered **wrong**. With that in mind, set `Option Strict On` in your project and IDE settings. — Konrad Rudolph, Jun 22 '14 at 13:21

score 1 · Answer 1 · answered Jun 22 '14 at 11:24

1

Because o could be of type Student at runtime. Every class can be casted to Object.

answered Jun 22 '14 at 11:24

adjan

13,371
2
31
48

Thanks, But Student does not contain Hello()? – w0051977 Jun 22 '14 at 11:34
1

As I said, it *could* be of type `Student`. The compiler does not know it. – adjan Jun 22 '14 at 11:35

Ňɏssa Pøngjǣrdenlarp · Answer 2 · 2014-06-22T13:13:33.317

Public Class Student

    Public Overridable Sub Test()
        Console.WriteLine("Hello, I am a student.")

    End Sub

End Class

Public Class Undergraduate
    Inherits Student

    Public Overrides Sub Test()
        MyBase.Test    ' skip this if this class COMPLETELY
                       ' replaces the base class functionality
        Console.WriteLine("...and I am an undergrad.")

    End Sub
End Class

Dim a As New Student
Dim b As New Undergraduate

a.Test
b.Test

Output:

Hello, I am a student      ' from a
Hello, I am a student      ' from b's MyBase.Test
...and I am an undergrad.  ' from b

Your question relates to late binding. By passing o as Object, the IDE cannot tell whether the Hello method is available on a given object. It might be and it might not be. If you have Option Strict On the default settings will not allow this to compile for just this reason. If you are sure you know what you are doing, you can customize the error to change Late Binding errors to warnings or even ignore them.

The restructured code may give a better view of using inherited classes to avoid needing to use late binding and because passing an object to itself is a little odd.

VB is only "odd" in that `Option Strict Off` removes the constraint allowing it to be different than C#. In C# you can use `dynamic` to basically implement Option Strict Off. see also http://msdn.microsoft.com/en-us/library/0tcf61s1.aspx — Ňɏssa Pøngjǣrdenlarp, Jun 22 '14 at 13:12

score 0 · Answer 3 · answered Jun 22 '14 at 13:04

The last time I used late binding was in C#. I have discovered that Visual Basic seems to be a bit of an exception as described here:

" Visual Basic uses them whenever the variable is of type Object and the compiler directive "Option Strict Off" is in force "

Source Wikipedia: http://en.wikipedia.org/wiki/Late_binding#Late_binding_in_.NET.

score 0 · Answer 4 · edited May 23 '17 at 11:49

0

Because you forgot to turn Option Strict On.

Really, it's the first thing one should do when creating a new VB.NET project, and it's a really pitty that it isn't enabled by default.

A list of which compile-time checks are added with Option Strict On can be found on MSDN:

http://msdn.microsoft.com/en-us/library/zcd4xwzs.aspx

edited May 23 '17 at 11:49

Community

1
1

answered Jun 22 '14 at 13:18

Heinzi

167,459
57
363
519

Compile time v runtime exceptions

4 Answers4