Exception handling dilemas

I am writing a small component to allow querying of a TV schedule listing. At the moment it's an XMLTV format xml file, but I may change this to an SQL database later.

I am using the factory pattern to return an instance of an object implementing an interface (ProgrammeFetcher) with (currently) one concrete class XMLProgrammeFetcher.

I'm getting into a muddle about Exception handling though. I'm developing the component with just a standard main() method to test, but it will ultimately be deployed as part of a Servlet.

At first I thought if I just kept throwing the Exceptions back up the method stack I could eventually catch them in the main() or doGet() methods and handle them appropriately (either System.err.println() or forward("errors.jsp") or whatever).

But... I've found a snag with this approach.

While fetching a programme from the listing a DateFormat ParseException can be thrown if the start or stop attribute is unparseable by the DateFormat instance.

I can't simply throw this Exception because I don't want it to be fail fast. I want it to carry on with the rest of the programmes its fetching even if one of them fails.

For the moment I'm going to catch the ParseException and set the start/stop Date instance(s) to null and return the Programme with the null Dates. Requiring that code elsewhere can (if need be) handle the null Dates sensibly, remove them from the output and output an warning message where appropriate.

I'm asking the question in here however, because this is a problem I've come across before when code may be deployed in different environments where simple try{} catch() { System.err.println(); } may not be appropriate or even available.

Are there any defacto design patterns/solutions to this problem?

Thanks,

Paul

[1845 byte] By [PCampbella] at [2007-11-27 4:09:59]
# 1
log4j
corlettka at 2007-7-12 9:15:29 > top of Java-index,Java Essentials,Java Programming...