Simple answer: no. There are basically two types of methods in .NET world. First those do not return any values (void methods in C# or subroutines in VB). Second those methods which do return some values (non void methods in C# and functions in VB)So, failing to have a return statement where the calling code expects one, should be reason enough to cause a compilation error. Not so in VB.NET 2005, at least not with the default configuration.Couple of days ago I spend few minutes understanding this same issue. Yes, not explicitly returning any value from a function is a huge programming error. But it becomes even worse when you don’t get to know it until runtime.The value returned to the caller when there isn’t any explicit return statement in the code is the default value for the return type of the function. Or in other words, the result will be as if you have returned nothing. For example, if you have following function in your code:Private Function test() As IntegerEnd FunctionThen somewhere else have this statement:MessageBox.Show(test.ToString())The program will compile normally and produce a message box with 0 (the default value of integer) in it. If we change the return type of the test method to string, the function will be returning nothing (return nothing) the default value for any object.Does anyone know any way around this issue, any changes to configuration? So that VB.NET compiler becomes stricter? Yes, it isn’t such a problem. But still, the compiler should alert us to such silly mistakes which we may make time to time.