On 6/25/08, Felix Meschberger <[EMAIL PROTECTED]> wrote: > Hi, > > Tobias Bocanegra schrieb: > > > On 6/25/08, Carsten Ziegeler <[EMAIL PROTECTED]> wrote: > > > > > > > > > This interface will primarily be used to implement the [Value]Map > adapter > > > > > > > for JCR Node based resources but may also be used for other adapters to > be > > > done in the future - e.g. an adapter for Bundle-based Properties files > which > > > provide the properties data. > > > > > > > The interface would live in the org.apache.sling.api.resource and > > > > > > > therefore be an enhancement of the Sling API. > > > > > > > > > > > > > > Yes, sounds good to me - I guess it will still be possible to just > adapt > > > a resource to a plain old Map :) > > > Just one question= What happens if the value can't be converted to the > > > given type? Will just null be returned or an exception thrown (I imagine > the > > > latter)? > > > > > > > i think that the underlying JCR value.get*() method is called. eg: > > when requesting a 'long' property, the > > node.getProperty().getValue().getLong() is called. if the > JCR call > > fails with a ValueFormatException, it should be converted a respective > > runtime exception, either NumberFormatException, or > > IllegalArgumentException. > > > > although in a scripting environment, i don't care if the conversion > > can't be done. the net effect is, that i don't have the value i > > requested, and i need to use some meaningful default. so maybe > > ignoring the ValueFormatException and just return the default value > > would be more useful. > > > > Oh, I missed the point of Carsten's question. > > Of course this situation is interesting. I would say, neither of the > methods throws. Just as Map.get(Object) does not throw on missing entries, > the get(String) method of this map should not throw in this situation. > > For get(String, Object defaultValue): I think failure to convert should be > treated just like a missing value and the default should be returned. The > situation should be logged, though (DEBUG ?). > > For get(String, Class<T> type): Same here: If the value cannot be > converted, this should be treated as a missing value and the error be > logged. > > If we think conversion failure is special, both methods should throw in > this case. I suggest a new ValueConversionExceptions extends SlingException > which has as its cause the JCR ValueFormatException.
i'm rather for the returning NULL resp. the default value behavior. regards, toby
