exceptions

["Dhanji R. Prasanna" <dh...@gmail.com>]

Hi

I am having the same old issue with exception handling that has been
raised in every JSF forum since the beginning of time (!)
Sorry if this intrudes.

Is there any way to catch an exception thrown by the facesrender cycle
(example, a misspelled bean-property binding) and redirect to a
friendly error page? The delegator servlet (a custom servlet which
simply wraps all service calls and delegates to JSF) does not solve
this issue as part of the page has already been flushed to the output
stream when the exception is thrown, resulting in a blank page.

Also am I to assume that the errorPage directive in web.xml will only
be used if underlying exceptions (thrown inside say, an
actionListener) is wrapped and rethrown as a FacesException?

Is there a best-practise to dealing with exceptions in Backing-bean
constructors (and subsequently redirecting to a friendly error page)?

Thank you,

Dhanji.

Re: exceptions

["Dhanji R. Prasanna" <dh...@gmail.com>]

Thanks for the help Mario (the ugly exception page rises like a
zombie!). Im still encountering the blank page even when extensions
filter is applied. However I noticed a couple of things that could be
at issue:

- This is the filter I am using (which appears to be differnet from
the one in myfaces' page)
        <filter-class>org.apache.myfaces.component.html.util.ExtensionsFilter</filter-class>

- I am also using PlanetJ's compressing filter--how do I control the
sequence of application of these filters (which should go first)? And
has anyone seen the two used together before?

Thanks for your help in advance.

Dhanji.

On 6/20/06, Mario Ivankovits <ma...@ops.co.at> wrote:
> Julian Ray schrieb:
> > There is some discussion on this topic in the WIKI that you might want to
> > look at.
> >
> Hey, pretty new wiki page
> (http://wiki.apache.org/myfaces/Handling_Server_Errors)
> Happily its not that different to my approach, except that I do not use
> JSF to output the error page.
>
> Also it might be great to update the wiki and make use of
> org.apache.myfaces.shared_tomahawk.util.ExceptionUtils to get the real
> exception. It uses reflection to see if there is a "getRootCause" method
> and so can also deal with JasperException.
>
> Ciao,
> Mario
>
>

Re: exceptions

[Mario Ivankovits <ma...@ops.co.at>]

Julian Ray schrieb:
> There is some discussion on this topic in the WIKI that you might want to
> look at. 
>   
Hey, pretty new wiki page
(http://wiki.apache.org/myfaces/Handling_Server_Errors)
Happily its not that different to my approach, except that I do not use
JSF to output the error page.

Also it might be great to update the wiki and make use of
org.apache.myfaces.shared_tomahawk.util.ExceptionUtils to get the real
exception. It uses reflection to see if there is a "getRootCause" method
and so can also deal with JasperException.

Ciao,
Mario

RE: exceptions

[Julian Ray <ju...@yahoo.com>]

There is some discussion on this topic in the WIKI that you might want to
look at. 

-----Original Message-----
From: Mario Ivankovits [mailto:mario@ops.co.at] 
Sent: Tuesday, June 20, 2006 1:47 AM
To: MyFaces Discussion
Subject: Re: exceptions

Hi!
> I am having the same old issue with exception handling that has been 
> raised in every JSF forum since the beginning of time (!)
First, to get rid of the "blank page" problem it should be possible to use a
servlet filter which buffers the whole response (also ignores any flush).
This might slightly increase the latency, but if you use e.g.
the ExtensionsFilter this buffering already takes place.
You do not have to do any further processing of the response, so the
response time at all shouldn't increase that way.
Again, if you use the ExtensionsFilter and NOT the StreamingAddResource this
buffering already takes place, so there should be no need for this filter,
except you have huge parts of jsp/html outside your f:view component.

Second, I use the web.xml strategy too. So adding
    <error-page>
        <error-code>500</error-code>
        <location>/error.jsp</location>
    </error-page>
do the "friendly error page" trick.

At last you might get a copy of error.jsp from tomahawks "simple"
example (tomahawk/examples/simple/src/main/webapp/error.jsp) there you will
find the code required to get the real exception (which is not that easy as
it might sound - well, ok, if you know the trick its easy again
;-) )

RIP ugly exception page.

Ciao,
Mario

Re: exceptions

[Mario Ivankovits <ma...@ops.co.at>]

Hi!
> I am having the same old issue with exception handling that has been
> raised in every JSF forum since the beginning of time (!)
First, to get rid of the "blank page" problem it should be possible to
use a servlet filter which buffers the whole response (also ignores any
flush). This might slightly increase the latency, but if you use e.g.
the ExtensionsFilter this buffering already takes place.
You do not have to do any further processing of the response, so the
response time at all shouldn't increase that way.
Again, if you use the ExtensionsFilter and NOT the StreamingAddResource
this buffering already takes place, so there should be no need for this
filter, except you have huge parts of jsp/html outside your f:view
component.

Second, I use the web.xml strategy too. So adding
    <error-page>
        <error-code>500</error-code>
        <location>/error.jsp</location>
    </error-page>
do the "friendly error page" trick.

At last you might get a copy of error.jsp from tomahawks "simple"
example (tomahawk/examples/simple/src/main/webapp/error.jsp) there you
will find the code required to get the real exception (which is not that
easy as it might sound - well, ok, if you know the trick its easy again
;-) )

RIP ugly exception page.

Ciao,
Mario