VB6 Error Handling in Properties -> Best practise? - properties

Question

im using CodeSmart 2013 to analyze my VB6 projects.
The review function says i should add error handling (or at least "on error resume next") to my class-properties.
My properties typically look like this (in 99% cases):
Public Property Let PLZ(ByVal strPlz As String)
myStrPLZ = strPlz
End Property
Public Property Get PLZ() As String
PLZ = myStrPLZ
End Property
When i automatically add error handling it would look like this:
Public Property Let PLZ(ByVal strPlz As String)
'<EhHeader>
On Error GoTo PLZ_Err
'</EhHeader>
myStrPLZ = strPlz
'<EhFooter>
Exit Property
PLZ_Err:
MsgBox Err.Description & vbCrLf & _
"in TNV.frmSucheTeilnehmer.PLZ " & _
"at line " & Erl, _
vbExclamation + vbOKOnly, "Application Error"
Resume Next
'</EhFooter>
End Property
Public Property Get PLZ() As String
'<EhHeader>
On Error GoTo PLZ_Err
'</EhHeader>
PLZ = myStrPLZ
'<EhFooter>
Exit Property
PLZ_Err:
MsgBox Err.Description & vbCrLf & _
"in TNV.frmSucheTeilnehmer.PLZ " & _
"at line " & Erl, _
vbExclamation + vbOKOnly, "Application Error"
Resume Next
'</EhFooter>
End Property
is anyone practically doing error handling in properties? is this best practise? because this would be a lot of additional code to my projects (code overview decreases imho)
Thx for help!
Greetings from germany
SLimke

Answer 1

You should add error handling in just the same way as you would in any method (Sub/Function).
My rule of thumb is that if the method is only a couple of lines long and doesn't do anything exotic then there is no error handling required. The same can be said of a property Get/Set
Yes adding error handling to all your property getters and setters generates a lot of code so one option could be to use centralised error handling. See this post for some discussion of this: Centralized error handling in VB6

Answer 2

Don't take these guidelines (especially from a program written by someone with their own opinion of what "best practice" entails). I've never used it so I can't speak (nor do I doubt) it's quality... just saying.
MarkJ is also right. If you don't need any validation on property setting then just make them public variables. If you later need to add validation, making them into private variables and having the public Property Get/Let/Set instead won't break the interface and no other code changes are needed.
As for adding error handlers in every class property get/let? Why? Personally, I assume if someone is going to use my class they will at least take a moment to make sure they know what the !##$ they are doing and how to use it. If they set a property so incorrectly that it causes a runtime (or compile-time) error then they will know right away.
If the value for setting the property is coming from the user, i.e.
MyClass.SomeProperty = Input("Enter something: ")
Then I personally think the error code should be placed there. i.e.
On Error GoTo StupidUser
MyClass.SomeProperty = Input("Enter something: ")
Exit Sub
ErrorHandler:
MsgBox "You did not supply a correct value!", vbExclamation
Otherwise, what are you going to do when you handle an error in your class? Pass it on to a centralized error handler which will just create more code to follow and end up with the same result? The user being notified/written to a log/etc.?
I (again, personally... programming isn't black & white) prefer to put error handling code in the caller routine... the procedure that's using the class, setting properties, etc.
Any sort of "code optimizer/checker" is written by a person or multiple, and even reputable ones will bring up debate among those who use it on how it should work.
TL;DR: some recommendations can be safely ignored.

Answer 3

Why not use public fields instead of these boilerplate properties?
Public PLZ As String
If you later need to add logic, no problem! You can convert public fields to properties without breaking clients.