Also consider if it makes sense to simply return 'null' instead of throwing an exception. This is particularly worth doing with methods that will often be used in templates, since you can't put a try/catch round sections of a template ;-)
L.
Quinton McCombs wrote:
Just an update on my progress on this issue - - I have back ported all bug fixes from the Fulcrum version. - I have merged in changes that Henning made in his version of Intake to allow for multiple xml definition file. - I have fixed the defect described in TTWS20. - I have converted all logging to commons-loggingNext: - Improve error handling & reporting - Testing - Update the javadocs, DTD, and xdocs - Try to come up with some Junit tests I have had one request to change the the IntakeTool to prevent it from throwing Exception when on the getGroup(name) method. I was thinking about changing this to throw IntakeException which would just be a subclass of TurbineException. I could also throw IntakeException to be the exception thrown any time the intake service encounters an unrecoverable error. Any comments on this idea? >-----Original Message----- >From: Quinton McCombs [mailto:[EMAIL PROTECTED]] >Sent: Friday, December 13, 2002 12:20 AM >To: Turbine Developers List >Subject: Changes to intake service > > >I am about to start working going through the entire intake >service and making some changes. When I first got started >with intake, it was a little confusing at first (2.1). >Seeing the posts on the user's list, this is an area where >many people seem to have some trouble. My main goal is to >make it a little easier to get working for people new to Turbine. > >Here is a brief list of things that I am planning to address. >- Better error reporting to the log file. It can be very >difficult to troubleshoot a simple mistake in intake.xml. >- Fix the problem of not being able to set a mapped property >to null. >- Update the documentation to fully describe the types of >fields, attributes, available rules, etc. >- Backport any bug fixes in the fulcrum version back to the >coupled version. >- Update the javadocs >- Better error handling >- Develop some JUnit tests > >Is there anything else that anyone would like to suggest? > >Have we decided on what to do about logging? I suppose that >I could just keep it using the current logging mechanism if >that debate is not over yet. > > > > > >-- >To unsubscribe, e-mail: > [EMAIL PROTECTED]> >For >additional commands, >e-mail: > > -- To unsubscribe, e-mail: For additional commands, e-mail:
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
