if we find a nice api for this fine by me.
johan
On 5/8/07, Bart Molenkamp <[EMAIL PROTECTED]> wrote:
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.
>> > >
>> >
>>
>