On Wed, Sep 24, 2014 at 5:30 AM, Chris Mylonas <ch...@opencsta.org> wrote:
> > The SliderSectionServiceImpl throws higher up the stack - can this pass >>> the exception up to setupRender? I thought "throws SystemException" would >>> have been enough? >>> >> >> What about having your code handling the exceptions itself, when it calls >> the EJB methods that can throw exceptions? >> >> > Handling is adding a tonne of work, just on the slider component I've had > to muck around with several page classes, the service implementing class > and the value encoder now returns null just for hackiness tests - maybe not > so much in this project because it's little, but I have another larger > project to hit the books on so-to-speak, so am using this smaller project > to see my best options. My re-thrown message has come up but it's exactly > what I was hoping to avoid ##below > > > Another option: have you tried adding an onException(Exception e) method >> to your component? >> > > Yes. And in the onException method I try and return a different page that > has @InjectPage in the component class. > Using tapestry-hibernate I think the errors pop upwards much nicer - that > could be EJB FUD I'm stirring, it's quite late and my comedy hour is nearly > here, just warming up :) > > >> Another option: override the Tapestry error page. >> > > You know, I think this one will do the job. I may just have to make a > hashtable of error codes to friendly-configure-this-component-yourself page > for the component ##above. Hashtable or service would be nicer - My first > ever tapestry service was for converting netmask to stroke notation for a > select i.e. 255.255.255.0 to /24 - I know how much code that saved!!! > In 5.4, you can contribute to the default error page and map exception types to specific error pages ( http://tapestry.apache.org/5.4/apidocs/org/apache/tapestry5/internal/services/DefaultRequestExceptionHandler.html - that reminds me, I should add information about that to the user guide as well). Kalle
