On Sat, Jul 2, 2011 at 10:28 AM, Jörg Schaible <joerg.schai...@gmx.de>wrote:
> Hi, > > Henri Yandell wrote: > > > These are the current blocking items in play afaik: > > > > * Email thread - what else should implement Formattable? > > * LANG-696/Email thread - getShortName. What to do with the (String) > > variant. Remove others. > > * Email thread - Validate method naming > > I just re-read the thread: http://markmail.org/message/ml7efpvqezysvs2p?q=Validate+list:org%2Eapache%2Ecommons%2Edev/ Since this has gone quiet, I was going to follow through and rename the validate* method (which are all @since 3.0) to check*. Someone else like it it ;) But have two different verbs is smelly: Validate.check*(), As I mention in the thread, a validator validates a state, so I like best: Validator.validate*(). But changing an existing class name seems more controversial and possibly more trouble than it is worth. If it were just up to me, I would just bite the bullet and do it for the sake of nice and pretty, but I am concerned about downstream users. Thoughts? Gary > Can somebody else give the ContextedException stuff a review? I used in the > meanwhile a copy of it in a project, but a method name is bugging me. > > What's it about? The exception provides a context for additional > information, just think of a map with key/value pairs. The problem that it > solves: > > Instead of writing: > > throw new MyCommunicationException("The connection to " + host + ':' + port > + " failed for " + user + " because of invalid credentials"); > > you have: > > throw new MyCommunicationException("Invalid credentials for > connection").addValue("host", host).addValue("port", port).addValue("user", > user); > > And you're able to enrich the context in a bigger scope: > > try { > ... > } (catch MyCommunicationException e) { > throw e.addValue("Module", "backup"); > } > > Fine so far. The values are properly formatted in table form in case of a > message and you may even access the individual values. A problem arises in > recursive algorithms (e.g. SAX Handler) with: > > try { > ... > } (catch MyException e) { > throw e.addValue("Current Handler", handler.class.getName()) > .addValue("Current Line", line); > } > > This would normally clobber the "Current Handler" in a nested handler > situation. Our implementation will therefore detect the key clash and add > the new value with key "Current Handler[1]" (and will increase the index > for > more values). However, the current line in the processed XML is always the > same and does not change, but would be added over and over again for each > recursive step. > > Therefore the ExceptionContext defines the method "replaceValue(key, > value)" > ... and this is bugging me, since for me it is "setValue(key, value)". > Typically *I* would use setValue for the normal case and only in recursive > situations addValue. Can somebody review this interface and also the method > documentation, because *I* have a clear idea what add/set should do, but > the > method description gives a lot of possibilities about its purpose and how > it > can be implemented. What do you think about this API? > > Cheers, > Jörg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Thank you, Gary http://garygregory.wordpress.com/ http://garygregory.com/ http://people.apache.org/~ggregory/ http://twitter.com/GaryGregory
