Throw RuntimeExceptions only from XmlBuilder.create

[davidmoten]

When I want to create some small bit of xml the builder is great but having to catch exceptions is horrible.

To make everyone's code cleaner you could wrap the ParserConfigurationException with a new ParserConfigurationRuntimeException and ditto for FactoryConfigurationError wrapped by FactoryConfigurationRuntimeException. Then XmlBuilder.create could throw only RuntimeExceptions and those that wanted the detailed catch behaviour could catch them. Forcing the handling of checked exceptions in a library aiming for code brevity with chaining is a shame in my opinion.

[jmurty]

I am open to the idea of adding a new create method -- maybe createWithRuntimeExceptions -- to do something like this but am not prepared to change the existing methods as there is too much chance it would break badly with existing code.

I agree that catching exceptions is awful, but this is Java and java-xmlbuilder just passes on the awfulness without messing with things too much.

[davidmoten]

I reckon you will get people into this builder if you just go with breaking the api in v2.0. Don't throw any checked exceptions and suddenly it will become a tool pleasurable to use. You have gone to the trouble of supporting method chaining, just go the extra mile with the exceptions and bingo!

My use case for instance the exceptions were awful. I was building fragments to place in certain places in a template xml and as such was calling XmlBuilder.create many times within loops etc. Very ugly having completely unnecessary catch clauses everywhere. By the way XmlBuilder.asString also throws a checked exception (TransformerException).

If you did add the new createWithRuntimeExceptions method that would help but we need to cover other commonly used methods as well like asString.

[jmurty]

Maybe the best thing to do would be to create an XmlBuilder adapter/wrapper class that is responsible for "suppressing" checked exceptions, as an additional interface rather than breaking backwards-compatibility altogether. That way, users could choose their preferred approach: checked or unchecked.

I'm having trouble coming up with a good name for the adapter, something like XmlBuilderUnchecked or QuietXmlBuilder.

I would also rather capture multiple checked exception types into a single XmlBuilderRuntimeException rather than creating an alternative unchecked version for each checked exception.

@davidmoten What do you think?

[davidmoten]

Sounds good to me. The exception would be wrapped so that someone who is
keen can use the exception cause.

If you're happy to make another builder that would be great. Something a
little less wordy might be good, even XmlBuilder2.
On 27 Jun 2014 07:24, "James Murty" notifications@github.com wrote:

Maybe the best thing to do would be to create an XmlBuilder
adapter/wrapper class that is responsible for "suppressing" checked
exceptions, as an additional interface rather than breaking
backwards-compatibility altogether. That way, users could choose their
preferred approach: checked or unchecked.

I'm having trouble coming up with a good name for the adapter, something
like XmlBuilderUnchecked or QuietXmlBuilder.

I would also rather capture multiple checked exception types into a single
XmlBuilderRuntimeException rather than creating an alternative unchecked
version for each checked exception.

@davidmoten https://github.com/davidmoten What do you think?

—
Reply to this email directly or view it on GitHub
#4 (comment)
.

[jmurty]

@davidmoten I have pushed an initial implementation of a new XMLBuilder2 class with runtime-only exceptions to the branch "feature/remove_checked_exceptions". Would you be able to take a look and see what you think?

[davidmoten]

I had a skim through the changes James and looks fine, thanks.

[davidmoten]

Having used inheritance to make XmlBuilder and XmlBuilder2 you should probably make the classes final to prevent users inheriting from those classes and introducing unwanted side-effects. Rationale is in Effective Java by Joshua Bloch but you are probably familiar with it. You could instead refactor the classes to use composition so that users can inherit from your classes without unwanted side-effects.