commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <joerg.schai...@gmx.de>
Subject Re: [CSV] CSVFormat validation - do this earlier?
Date Wed, 14 May 2014 20:20:09 GMT
sebb wrote:

> On 13 May 2014 16:53, Benedikt Ritter <britter@apache.org> wrote:
>> Hi,
>>
>>
>> 2014-05-13 12:06 GMT+02:00 sebb <sebbaz@gmail.com>:
>>
>>> At present, validate() is not invoked until the format is used. This
>>> means that invalid arguments are not detected at the point they are
>>> provided.
>>>
>>> It would be possible to run validate as part of the withArgument()
>>> methods. This would allow earlier detection, and avoid the issue that
>>> currently some incorrect arguments may generate ISE rather than IAE.
>>>
>>> I think the only possible user problem is that escape must be set
>>> before using Quote.NONE as the policy, but this could be documented.
>>> Otherwise AFAICT the arguments can be set in any order.
>>>
>>
>> Validating the format when it is constructed rather then when it is used
>> is a good idea. But I think the only way to do this in a usable way is to
>> use the builder pattern. There are several field that depend on each
>> other during the validation. We don't want end up having user to look up
>> the validate code in order to be able to create formats...
> 
> I agree it would be better to use the builder pattern, but I lost that
> argument.
> 
> I think it should still be possible to validate each argument
> separately, even though they do depend on each other.

It is perfectly possible if you make the builder a bit smarter.

> However, it would prevent some subsequent changes to formats unless
> they were done in the correct order.

The builder can ensure that.

> e.g. if one wanted to swap the escape and delimiter characters that
> would be a bit tricky.
> But I don't see the need to support all possible sequences of updates
> to formats, so long as a format can easily be fully configured
> initially.

You can. See the builders for the ProxyToys at Codehaus, e.g. Decorating or 
Delegating:
- 
http://svn.proxytoys.codehaus.org/browse/proxytoys/trunk/proxytoys/src/main/java/com/thoughtworks/proxy/toys/decorate/Decorating.java?r=HEAD
- 
http://svn.proxytoys.codehaus.org/browse/proxytoys/trunk/proxytoys/src/main/java/com/thoughtworks/proxy/toys/delegate/Delegating.java?r=HEAD

The idea is to offer only the currently interesting setters unless you get a 
valid definition to build your target. It's a bit more effort, but 
absolutely foolproof for users.

Cheers,
Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message