Runtime Error 394: “Property Get can't be executed on write-only property,” explained and fixed
Error 394, “Property Get can't be executed on write-only property”, fires when code tries to read the value of a property that accepts values but never returns them. Write-only properties are deliberate: the textbook example is a password or connection secret the object will accept and use but will not disclose, so that running code (and anything inspecting it) cannot extract it. Reading one raises error 394 immediately. It is a design feature behaving as designed; the bug is in the code that assumed every settable property is also readable.
For people who just run the program
- This is a developer-facing error. It happens in code that reads back configuration values from objects, often in generic save/restore or diagnostic routines that treat all properties alike.
- Note the feature. Settings screens that redisplay saved values, and tools that dump an object's configuration, are where reads of write-only properties sneak in.
- No setting unlocks the value. The object will not return it by design; that is the point of the property.
- Report the number to the maintainer. The fix is to keep the value in the program's own records instead of expecting the object to give it back.
For people who write the code
- Keep your own copy of values you will need again. When code sets a write-only property and later logic needs the value, store it in a variable or your own settings at the moment it is set:
connSecret = BuildSecret()
obj.Password = connSecret ' write-only: accepted
' savedSecret = obj.Password ' error 394: never readable
' use the connSecret variable you kept instead
- Make generic property walkers skip unreadable properties. Reflection-style loops over an object's properties must trap 394 (and its cousin 393) per property. A configuration dump that dies on the first secret is a tool that never finishes.
- In your own classes, use write-only deliberately and document it. A Public Property Let with no matching Get is the mechanism. Reserve it for genuine secrets or one-way commands; using it for ordinary state frustrates legitimate callers and guarantees this error in their tooling.
Error 394 does not mean the value was rejected. The write succeeded; only the read is forbidden. Code that catches the error and “retries” by setting the value again is harmless but pointless; the correct change is to stop reading.
If it still happens
If a property you know is readable raises 394, the object reference may point at a different class than expected, one whose same-named property is write-only. Check TypeName at the failure; same-named properties with different access patterns across classes are a real and confusing species of this bug.
Common questions
Why would a property be write-only? To accept a value without ever disclosing it. Passwords and secrets are the standard case: the object can use the value internally while guaranteeing that no later code can read it back out.
How can I verify a setting took effect if I cannot read it? By behavior: attempt the operation the setting enables and observe success or failure. Write-only properties are verified by use, not by inspection.
Related errors