I don't agree with that though. We (at Teachscape) are using the
override as using the setting is just too simplistic. Imho an example
of where convenience won from a better approach.

This is what we do:

        public Page onRuntimeException(Page page, RuntimeException e) {

                if (e instanceof AuthorizationException) {
                        return super.onRuntimeException(page, e);
                } else if (e instanceof PageExpiredException) {
                        Ts4Session session = Ts4Session.get();
                        if (session.isTemporary() || session.getUserId() == 
null) {
                                // this was an actual session expiry
                                log
                                                .info("session expired and request 
cannot be honored, cycleId: "
                                                                + cycleId);
                                return super.onRuntimeException(page, e);
                        } else {
                                log.error("unable to find page for an active 
session!");
                                // hmmm, we have a logged in user, but the page 
could not be
                                // found. Fall through to display an error page 
or exception
                                // page
                        }
                }

                if (Application.DEPLOYMENT.equals(Application.get()
                                .getConfigurationType())) {
                        return new ErrorPage(e, page, cycleId);
                } else {
                        return new ExceptionErrorPage(e, page);
                }
        }

And while ErrorPage doesn't display the exception to end-users, it
still wants to use it for logging etc. I don't know why we ever
thought we wouldn't need the exception in a user-facing error page.
FYI, the error page also has a (stateless) form for getting feedback
from the user. Error log statements are all mailed, and the initial
exception log and the optional user report are linked together by a
unique request cycle identifier.

Anyway, if you ask me, we should give our error handling a close look
some time, and simplify without oversymplifying like we've done
before.

Eelco

On 5/8/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
I think we had that method on application but that was moved again.

But why do you want to change the ExceptionErrorPage?
That is just there for debugging, Normally in production you would see the
InternalErrorPage
that can be set through the settings.

johan


On 5/8/07, Bart Molenkamp <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I think it's currently too hard to show a custom exception page. To do
> so, I need to override Application.getRequestCycleFactory(), return my
> own IRequestCycleFactory implementation, that can build my subclass of
> WebRequestCycle that overrides the onRuntimeException() method.
>
> Maybe it's easier to define a method on WebApplication:
>
> Page onRuntimeException(Page page, RuntimeException e) {
>    return null;
> }
>
> And call this method from WebRequestCycle.onRuntimeException. By default
> this would have the same behavior as it is implemented now, but it's
> much easier to create a custom error page because I only have to
> override onRuntimeException in my WebApplication subclass.
>
> Bart.
>

Reply via email to