Community
Participate
Working Groups
The preference substitution mechanism should try to check for the following: - invalid substitution syntax (e.g. missing close brace) - undefined substitution - cyclic references There are probably other error conditions to look for.
The issue of what constitutes an error in a preferences substitution is a bit tricky. One complication is that the substitution terms appear in Strings, and strings can have arbitrary (String) values, so at what point does an arbitrary String become a malformed substitution term? (In principle you could even compose a well-formed substitution term by combining substitution-term fragments and have that work perfectly well--if our substitution processing will support that. Conversely, you might be able to compose a problematic substitution term out of parts that were apparently ) Regarding undefined substitutions, I don't believe that these will directly cause any runtime errors. The substitution mechanism will return null for these, but null is represented as "null" in Strings. For example, if you look at the "Details" for an undefined substitution, the substituted value is "null." So the preferences mechanism is fairly tolerant of this kind of error. Another concern is where to do this error checking. I could put some checks into the action code of the PrefSpecs parser that could look for either of the above conditions (for some definition of possibly malformed substitution term) and report errors or warnings where problems are found. (Given the subjective or tolerable nature of these problems, warnings might be better.) That would help with the specification of default, "special", and "empty" values for String parameters. But then there are values that might be set through the preference page, i.e., through the field editors on the tabs. We could put in validity checks on string fields to look for problematic conditions. Actually, there are two times when you might check on the validity of a preference value on a page. One is when the field is edited, when problems are reported as errors and lead to the appearance of an error message--with red x--at the top of the preferences page. These would prevent the page from being applied or finished, which might be overly restrictive, at least for some possible errors. The other time to check is when the page is applied or finished. Then we can report warnings with a pop-up and the user can go forward or back. That's more flexible, but doesn't give the earliest notification about the errors. I think I'm in favor of the latter approach, except for errors that are really intolerable. Then there are the values that are set in the service through the service's API. For this I suppose we could add checks to the service to analyze values on their way in or out and post warnings or errors in the error log. As in the previous case, I'm not in favor of doing something as drastic as throwing an exception unless it seems likely that an exception will result later in any case. I suppose that for the most part it would be best to check for problems that involve a single field when the value is added to the store. On the other hand, for something like cyclic dependencies, it might be better to wait until the value is retrieved--in particular since cycles may be broken before the value is referenced and also considering that cycles may be created as well by the removal of preference values. I'm going to reassign this bug to me, although anyone who wants to work on it is welcome to. I don't think that the actual effect of most of these problems is very severe, so I may not get to it for a while, but I may work on bits and pieces over time. Please let me know if you have any suggestions.
Another possible problem: "${}"
Or, somewhat similarly, "${9876}", i.e., valid delimiters with an invalid preference identifier.
