commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <>
Subject Re: [convert] Use cases not currently covered
Date Tue, 23 Mar 2004 22:34:04 GMT
From: "Legostaev, Andrei" <>
> LA>> public interface Conversion {
> LA>>   public Object convert(Object value) throws Exception;
> LA>> }
> RB> I am not too sure about the Exception.  Throw-everything forces
> RB> the caller to Catch-everything.  Maybe a more specific Exception,
> RB> like ConversionFailedException, is sufficient.
> Stephen also raised this point.  My take is that a client would only
> ever invoke a Conversion through a manager.  So the only catching
> would need to be done in a handful of manager implementations.  On
> the other hand clients would at times implement Conversion as
> anonymous classes.  So allowing any exception to be thrown out of
> Conversion.convert() would take a large burden off clients and put a
> small one on implementors of managers.

On Andrei's suggestion, I incorporated the idea of throwing Exception from
all converters into the main convert CVS. It does simplify things for
implementations when any exception can be thrown.

The CVS interface currently defines
public Object convert(Object value, Converter converter) throws Exception;
although nothing uses the Converter yet. I included it as a way to get
additional data such as a Locale. However, there are other things that might
need to be passed in, such as a date formatting string for Date to String or
a ClassLoader for String to Class.

I wanted to keep the conversion objects as singletons where possible, so I
was considering
public Object convert(Object value, Object helper, Converter converter)
throws Exception;
where helper is any object necessary to allow the conversion to happen.
Somehow, this feels a bit vague though.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message