Functions or subs?

[Foxer]

When writing vb.net classes, I'm told that the only "things" that should be accessed by "the public" are properties and methods.

ie there shouldn't be any

Public Sub MySub()

declarations in a class. There might be private sub's within a VB class but the theory explained to me is that any public method should return a success/fail flag indicating that only public functions should be used (along with property set/get).

Is this best practice?

Do ppl use Public Subs? Is that considered bad form?


Is it better form for every method to be in the form of a public sub with parameters (including error codes). If a sub needs to return anything, it does so via parameter or by setting a property that can be read after calling the actioning sub? If that were so, then Public Functions wouldn't be needed within a class?



I bet someone will say "depends on the problem".

[Edneeis]

I don't know if this is just a symantical error but -'When writing vb.net classes, I'm told that the only "things" that should be accessed by "the public" are properties and methods.' - the term methods applies to functions and subs.

I use public subs all the time even the framework does, I've never heard that it was bad either. Where did you hear this?

[DevGrp]

I think he may be mixing them up. Functions, Subroutines, Subs and Methods all the same.

[Foxer]

If one takes the opinion that every call should return a success/fail flag as a minimum, one can argue that there is no place for Public Subs in classes.

This guy argues that only Public Functions should be used that :-

- receive parameters
- modify properties internal to the class
- return a success/fail flag

You can do all that with a Sub and parameters but functions are designed expressly for this purpose.

Is his arguement correct? Are public subs redundent if you take this line of thinking?

Public Class MyClass

   Public Sub MySub (byVal inputparam, byVal Succeed as boolean)
   ...
   End Sub


   Public Function MyFunction (byVal inputparam) as boolean
   'Returns success/fail flag
   ...
   End Sub

End Class

Am I wrong to use MySub when MyFunction is "better"?

[Edneeis]

Yes IF you follow his thinking then it would make Subs redundent, but why make everything return a Fail/Success bit? As I stated before this is not the pattern that the .NET framework itself follows.

[hellswraith]

And, if you implement the sub right, it should work. Now, if there is an error in the sub, you should be throwing an exception.

The normal expectations of a sub is that a code block is executed completely and successfully. If it isn't successful, it should throw an exception. This eliminates the need to return a true/false value. This is why when you call System.IO.File.Delete("myfile.txt"), the file is deleted. Now, if there was an error deleting the file, and IOException is thrown.

It is is up to the user of your sub to check for errors, but it is you that is supposed to throw exceptions when something isn't right.

[hellswraith]

The sub in this:

   Public Sub MySub (byVal inputparam, byVal Succeed as boolean)
   ...
   End Sub


   Public Function MyFunction (byVal inputparam) as boolean
   'Returns success/fail flag
   ...
   End Sub

in my opinion is not good. If you want to know success or failure, you should use the function way. Using arguments as output variables are not looked good upon by my development team. Of course, there are times when you need them (that is why they are there), but generally there is a better way to do things.

[Foxer]

Ta HellsWraith.

I tend to agree with you. There are oodles of ppl using Public Subs in classes and this guy reckons its bad form. Phooey to him I reckon.