because one page is meant for production use and another for development. you dont want your end customers seeing your stacktrace do you?
-igor On Thu, Apr 17, 2008 at 6:26 PM, Ned Collyer <[EMAIL PROTECTED]> wrote: > > > igor.vaynberg wrote: > > > > whats wrong with just subclassing requestcycle, overriding > > onruntimeexception, and returning any kind of error page you want? > > > > -igor > > > The app elegantly exposes other settings like pages for handling > AuthorizationException, PageExpiredException. > > Both of these extend WicketRuntimeException, so if I check for it in > onRuntimeException I'm going to lose the handling of anything thats > extending WicketRuntimeException unless I specifically exclude those > interfaces, and it makes it quite brittle if you guys change the behaviour > of "AbstractRequestCycleProcessor.respond" > > > getApplicationSettings().setInternalErrorPage(MyInternalExceptionPage.class); > seems so easy > why not > getApplicationSettings().setExternalErrorPage(MyExternalPage.class); > > > I guess a further question would be, why not just have a single exception > page (for both internal and external) that has scope to the exception so we > can handle it however we like, and allow us to extend this. (Ie, if > InternalErrorPage had scope to the exception or there was only one page, I > wouldn't have been posting here). > > -- > View this message in context: > http://www.nabble.com/Can-we-expose-ExceptionErrorPage-via-IApplicationSettings-please-%21-tp16758488p16758764.html > > > Sent from the Wicket - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
