I think most the exception infrastructure is focused around building up location / context information more so than exception types, though types are handled as well of course.. .
If you want to know how tapestry handles it right now take a look at: http://svn.apache.org/viewvc/tapestry/tapestry4/trunk/tapestry-framework/src/java/org/apache/tapestry/engine/AbstractEngine.java?view=markup I can see it being useful having a hivemind strategy / config point similar to how data squeezers "vote" for handling something being the means by which these exception presenters are chosen. I'll file a jira issue for it. On 3/8/07, Justin Walsh <[EMAIL PROTECTED]> wrote:
Is there a preferred way/pattern of handling application exceptions in a tapestry application. For example, I have a page, AuthorizationFailure.html which I want to display when a javax.ejb.EJBAccessException is thrown from the ejb layer, with a custom message etc. At the moment I'm plugging in my own ExceptionPresenter which sniffs out the root cause and delegates to a handler, defaulting to the exception page when a specific handler can't be found. But I'm wondering if I'm missing anything. Perhaps there are exception handler base classes that I can use? Or perhaps I can configure an exception presenter for a specific type of exception? Cheers -- Justin Walsh http://www.ewage.co.za --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Jesse Kuhnert Tapestry/Dojo team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
