Vladimir R. Bossicard wrote:
I've worked quite a bit with exceptions in cocoon, so here are my 2c of wisdom.
Thanks for the tip.
(rehashind the mail) > Do you have a strategy to fix this situation or other words of wisdom?
Below are some possible strategies.
I think that we are not very consequent regarding how we handle exceptions. Some examples:
protected void createDriver(String uri) throws XMLDBException { try { } catch (Exception e) { if (log.isInfoEnabled()) { log.info("Exception during creation of the Database", e); } throw new XMLDBException(ErrorCodes.INVALID_URI, uri, e); } }
1) deprecate XMLDBException and don't use it again
2) don't catch the exception here and make it bubble
3) use the real exceptions or make a XMLDBDriverNotLoadedException if the exceptions declared inside will change in the future. If not, use those.
protected void initResources(Document document)
throws XMLDBException {
try {
}
catch (Exception e) {
throw new XMLDBException(ErrorCodes.UNKNOWN_ERROR, e);
}
}
Don't catch it.
public DOMParser() throws XindiceException { try { } catch ( Exception e ) { throw new XindiceException("Error creating parser", e); } }
XindiceException is a somewhat generic exception.
Deprecate it. It should be used only by the top component to report specific Xindice exceptions to the user.
Well, you get the picture. And it's all over the place.
Another thing to consider is the chain of command for the calls.
If the calls are too nested and difficult to track down, probably it's because there is not sufficient componentization in the code.
If error handling cannot be easily made to bubble to more basic classes, it's usually time to review the classes and how they relate to each other.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------