I need access to the exception that caused the internal error, and if that can be done trough InternalErrorPage, then that's fine by me.

Instead of using this constructor reflection magic, maybe a simple factory interface can be defined that can create pages. So instead of having a setInternalErrorPage(...) something like createInternalErrorPage(Throwable t, Page p).

I think it's easier to understand such an interface instead of finding out that you can (but don't have to) add a constructor with one argument that takes the throwable as argument.

Bart.

Johan Compagner wrote:
ahh but this is not about our own ExceptionPage but more about
the InternalPage should be a bit better.

Why not look if that page has a Exception constructor param give it to it?

The problem i can see maybe is that we do a redirect to it.. (but i am not
sure)

johan


On 5/8/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:

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