I will look into this. The problem is that many people also use IntakeTool in java code as well. They might be trapping for the exception.
One idea would be overloaded method calls in IntakeTool which would accept a boolean parameter controling if an exception is thrown or if null is returned. The default would be to throw the exception. I do agree that methods which throw exceptions do present a problem for template designers. > -----Original Message----- > From: Laurie Harper [mailto:[EMAIL PROTECTED]] > Sent: Thursday, December 19, 2002 7:27 PM > To: [EMAIL PROTECTED] > Subject: Re: Changes to intake service > > > Definately change to use IntakeException rather than Exception or > TurbineException; the more specific an exception is, the easier it > becomes to do sane error detection and recovery. > > 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-logging > > > > Next: > > - 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:turbine-dev-> [EMAIL PROTECTED]> > For > additional commands, > e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
