Add possibility to produce a detailed error message #254
Conversation
Previously, the validation procedures were occuring in the #munge method. This was a problem because if #munge raises an exception, the error displayed to the user is opaque. If the data input is not valid, the error should be raised in the #validate method. This will ensure that the output given to the user includes information about the class, resource, and parameter which is in error.
afcdb72 to
551fab7
Compare
|
@reidmv if I'm reading this correctly, it doesn't add or remove any functionality at all, it just moves it to become more visible. Is that correct? |
This property previously set a default value of empty string, or ''. An empty string is not a valid dword or qword. This commit modifies the data property to not set a default value when the type is dword or qword. We probably shouldn't ever set a default value for data. For now though, by limiting the change to dword and qword types, we should avoid making any functional changes.
In order to enforce consistency, since the data property sometimes has a default value now and sometimes doesn't, make the property required. When we make the default value consistent, we will have the option of making this property not required.
|
@binford2k that is correct, or, that is the intention, yes. The objective is to eliminate the possibility of an error like the following from being encountered: And instead return an error like this one: Note that I've just added another two commits. I discovered that the real problem wasn't where the error was raised, munge vs. validate, but that the default value for the property wasn't passing validation when type was set to dword or qword. So, this commit now does include an additional internal change: it removes the invalid default value for those data types, but adds a type-level validation to require that the user set the property. Unfortunately, it doesn't look like there's currently an easier way to produce a sane error message without changing the behavior of registry_value in some way (even if minor). Puppet doesn't seem to have been built to accommodate the scenario of a type supplying a default value that doesn't pass its own validation routines... 🤷 |
|
Thank you for your contribution, @reidmv ! |
Previously, the validation procedures were occuring in the #munge
method. This was a problem because if #munge raises an exception, the
error displayed to the user is opaque. If the data input is not valid,
the error should be raised in the #validate method. This will ensure
that the output given to the user includes information about the class,
resource, and parameter which is in error.