Re: Handling Exceptions in ActionForm

[Michael Ruppin]

At your own risk, manipulate the ActionErrors and ActionMessages collections any way 
you like. 
They're in the request scope and named according to Globals.ERROR_KEY and 
Globals.MESSAGE_KEY.

m

--- Shane Mingins <[EMAIL PROTECTED]> wrote:
> Hi
> 
> I have a Swing app where the SwingView implements the view interface and has
> a method duplicateException(String s).
> 
> In the SwingView it is implemented as
> 
> public void duplicateException(String duplicateName)
> {
> JOptionPane.showMessageDialog(this, "That would result in a duplicate
> Channel", "Duplicate Channel",
>  JOptionPane.ERROR_MESSAGE);
> }
> 
> So if the business layer finds a duplicate it can inform the presentation
> layer.  I am wondering how this would map on Struts?
> 
> Using Struts, if I have an ActionForm implement the view interface, how
> would it create an ActionError or ActionMessage?  It seems that from an
> ActionForm the validate() method can do it, and an Action can do it but is
> it possible to create an ActionError and save it from my
> duplicateException() method?
> 
> Could I perhaps have my duplicateException() method add to collection
> variable in the ActionForm and then have the validate() method check that
> collection and generate the required ActionErrors?  
> 
> Any thoughts?
> 
> Shane
> 
> 
> Shane Mingins
> Analyst Programmer
> Assure NZ Ltd
> Ph 644 494 2522
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Handling Exceptions in ActionForm

[Karr, David]

> -Original Message-
> From: Shane Mingins [mailto:[EMAIL PROTECTED] 
> 
> Using Struts, if I have an ActionForm implement the view 
> interface, how
> would it create an ActionError or ActionMessage?  It seems 
> that from an
> ActionForm the validate() method can do it, and an Action can 
> do it but is
> it possible to create an ActionError and save it from my
> duplicateException() method?

Any validation logic in the ActionForm should only be basic syntactical
validation, and no semantic validation.  Semantic validation belongs in
your Action class, and likely in business logic called from your Action
class.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Handling Exceptions in ActionForm

[Shane Mingins]

Hi

I have a Swing app where the SwingView implements the view interface and has
a method duplicateException(String s).

In the SwingView it is implemented as

public void duplicateException(String duplicateName)
{
JOptionPane.showMessageDialog(this, "That would result in a duplicate
Channel", "Duplicate Channel",
 JOptionPane.ERROR_MESSAGE);
}

So if the business layer finds a duplicate it can inform the presentation
layer.  I am wondering how this would map on Struts?

Using Struts, if I have an ActionForm implement the view interface, how
would it create an ActionError or ActionMessage?  It seems that from an
ActionForm the validate() method can do it, and an Action can do it but is
it possible to create an ActionError and save it from my
duplicateException() method?

Could I perhaps have my duplicateException() method add to collection
variable in the ActionForm and then have the validate() method check that
collection and generate the required ActionErrors?  

Any thoughts?

Shane


Shane Mingins
Analyst Programmer
Assure NZ Ltd
Ph 644 494 2522



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Handling Exceptions

[Navjot Singh]

For ServletException, configure the error page in web.xml file. 
it will work.

navjot


|-Original Message-
|From: Mohd Amin Mohd Din [mailto:[EMAIL PROTECTED]
|Sent: Sunday, August 31, 2003 5:12 PM
|To: [EMAIL PROTECTED]
|Subject: Handling Exceptions
|
|
|Hi,
| 
|In struts-config, I have defined few global-exceptions such as these
| 
|  
|  
|  
|   
|  
|   
| 
|I also have created an error page, error.jsp with <%@ page
|isErrorPage="true" %> and at the top of the jsp template for all the
|pages a <%@ page errorPage="error.jsp" %>. However, when a
|ServletException occurs, it does not go to the path defined in
|struts-config.xml. Somehow, the error is still showing in the
|application page and not in any one of the error pages defined.
| 
|Thanks
|Amin 
| 
| 
|

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Handling Exceptions

[Mohd Amin Mohd Din]

Hi,
 
In struts-config, I have defined few global-exceptions such as these
 
  
  
  
   
  
   
 
I also have created an error page, error.jsp with <%@ page
isErrorPage="true" %> and at the top of the jsp template for all the
pages a <%@ page errorPage="error.jsp" %>. However, when a
ServletException occurs, it does not go to the path defined in
struts-config.xml. Somehow, the error is still showing in the
application page and not in any one of the error pages defined.
 
Thanks
Amin 
 
 

Re: Handling Exceptions

[Yann Cébron]

> However, when a
> ServletException occurs, it does not go to the path defined in
> struts-config.xml. Somehow, the error is still showing in the
> application page and not in any one of the error pages defined.

My guess is, the ServletException is happening someplace where Struts'
ExceptionHandler can't get hold of it, e.g. on your JSP page. Have a look at
your servlet container's logfiles to see exactly where they appear.

You can still define an error-page in your *web.xml* to catch those and
redirect them to your own error-page.

HTH,
Yann




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Handling Exceptions

[Alen Ribic]

You should probably create a global exception handler in your Struts
configuration file.
Something like this:


  


hope this helps
--Alen



- Original Message -
From: "Syed Kazim Hussain" <[EMAIL PROTECTED]>
To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]>
Sent: Thursday, June 19, 2003 7:52 AM
Subject: Handling Exceptions


> I have been using Struts as the MVC framework and Sitemesh as templates.
> It is working smoothly. Only problem is I want to forward the page to an
> error page whenever there is an exception.
>
> So in Tomcat, I have specified the option for forwarding the request to
> ErrorPage.jsp whenever we encounter a 500 Internal Server Error.
>
> But the page is not being forwarded. Instead an exception is thrown on
> the
> Error Page:
>
> java.lang.IllegalStateException: getOutputStream() has already been
> called for this response
>
> Any comments !
>
>
>
>
> -
> 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]

Handling Exceptions

[Syed Kazim Hussain]

I have been using Struts as the MVC framework and Sitemesh as templates.
It is working smoothly. Only problem is I want to forward the page to an
error page whenever there is an exception. 

So in Tomcat, I have specified the option for forwarding the request to
ErrorPage.jsp whenever we encounter a 500 Internal Server Error.

But the page is not being forwarded. Instead an exception is thrown on
the
Error Page:

java.lang.IllegalStateException: getOutputStream() has already been
called for this response 

Any comments !




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Handling exceptions in Action class

[chuckcavaness]

Take a look at my draft chapter on ExceptionException 
and see if that sheds any light on the topic.

You can download it here:
http://www.theserverside.com/resources/strutsreview.jsp

It's Chapter 10. You will need to register, but it's 
free.

Chuck
> Hi all:
> Can anyone kindly suggest, if i want to handle exceptions in the perform
> method of
> the Action class (like "LogonAction" class), how should I go go about?
> I thought of instantiating a ErrorAction Class from the perform method and
> pass parameters
> which would do the logging in the log file..(I want to log the exceptions in
> a log file.)
> I am not too sure of how to go about...
> Kindly suggest..
> 
> TIA
> 
> Vijeth
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Handling exceptions in Action class

[Vijeth R Naik]

Hi all:
Can anyone kindly suggest, if i want to handle exceptions in the perform
method of
the Action class (like "LogonAction" class), how should I go go about?
I thought of instantiating a ErrorAction Class from the perform method and
pass parameters
which would do the logging in the log file..(I want to log the exceptions in
a log file.)
I am not too sure of how to go about...
Kindly suggest..

TIA

Vijeth


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Handling exceptions

[Hani Hamandi]

Hmm, well, I think you should care about that.
If a JVM exception happens, there is most probably something wrong going on.
If you don't catch the exception/error, your user will get an ugly 505
server error or something like that. Your decision will depend on whether
this is okay in your application or not (from a product management point of
view). In our case, it was not. We prepared a nicely formatted Error page
with phone numbers and contact information apologizing for the inconvenience
... etc. We forward to this Error page is served whenever an "abnormal"
exception takes place, i.e., when we end up in the "catch Throwable" block
in validate() or in perform().

Hani.

-Original Message-
From: Dariusz Wojtas [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 04, 2002 4:06 PM
To: Struts Users Mailing List
Subject: RE: Handling exceptions


OK, that was helpful - now I see it from different perspective.
But what if somebody argues that Throwable catches
also JVM exceptions, like ThreadDeath or OutOfMemory
and similar? Should I care about that or not?
If not then why?

 Dariusz Wojtas


At 13:14 02-03-04 -0500, you wrote:
>Catching Throwable will catch both Exceptions and Errors. Catching
Exception
>will only catch Exceptions.
>You will want to catch Exceptions *AND* Errors to be bullet-proof.
>We were catching Exception for a while and we thought we were covered,
until
>one day we got (due to some weird deployment) a NoClassDefFoundError, which
>of course escaped the "catch Exception" and barfed right in front of the
>user in their browser as an ugly 505.
>
>So I think catch Throwable should be your final catch-all after you have
>handled all your "normal" exceptions.
>
>Good luck,
>Hani.


--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Handling exceptions

[Dariusz Wojtas]

OK, that was helpful - now I see it from different perspective.
But what if somebody argues that Throwable catches
also JVM exceptions, like ThreadDeath or OutOfMemory
and similar? Should I care about that or not?
If not then why?

 Dariusz Wojtas


At 13:14 02-03-04 -0500, you wrote:
>Catching Throwable will catch both Exceptions and Errors. Catching Exception
>will only catch Exceptions.
>You will want to catch Exceptions *AND* Errors to be bullet-proof.
>We were catching Exception for a while and we thought we were covered, until
>one day we got (due to some weird deployment) a NoClassDefFoundError, which
>of course escaped the "catch Exception" and barfed right in front of the
>user in their browser as an ugly 505.
>
>So I think catch Throwable should be your final catch-all after you have
>handled all your "normal" exceptions.
>
>Good luck,
>Hani.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Handling exceptions

[Hani Hamandi]

Catching Throwable will catch both Exceptions and Errors. Catching Exception
will only catch Exceptions.
You will want to catch Exceptions *AND* Errors to be bullet-proof.
We were catching Exception for a while and we thought we were covered, until
one day we got (due to some weird deployment) a NoClassDefFoundError, which
of course escaped the "catch Exception" and barfed right in front of the
user in their browser as an ugly 505.

So I think catch Throwable should be your final catch-all after you have
handled all your "normal" exceptions.

Good luck,
Hani.


-Original Message-
From: Dariusz Wojtas [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 04, 2002 1:01 PM
To: [EMAIL PROTECTED]
Subject: Handling exceptions


Almost every of my action classes has the try/catch block.
And I catch different types of exceptions that may be thrown
+ Throwable at the end

} catch ( ... ) {
log(...);
// add error;
} catch (Throwable t) {
log(...);
// add error

I found that in struts example apps, and in the struts source code,
there is always check for Throwable at the end.

But recently I was told that I should not use Throwable because it
is too high level, but Exception.
And now I am confused. May I use it or not?

Why does Struts use Throwable and not Exception?

Dariusz Wojtas


--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Handling exceptions

[Dariusz Wojtas]

Almost every of my action classes has the try/catch block.
And I catch different types of exceptions that may be thrown
+ Throwable at the end

} catch ( ... ) {
log(...);
// add error;
} catch (Throwable t) {
log(...);
// add error

I found that in struts example apps, and in the struts source code,
there is always check for Throwable at the end.

But recently I was told that I should not use Throwable because it
is too high level, but Exception.
And now I am confused. May I use it or not?

Why does Struts use Throwable and not Exception?

Dariusz Wojtas


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: RES: handling exceptions

[Ted Husted]

"Cakalic, James" wrote:
> I can't comment on the nested exceptions of 1.4 as I haven't really looked
> at this. But I would venture that my above comments apply there equally.

Nested exceptions are really a very good thing, and not hard to do
pre-1.4

http://www.javaworld.com/javaworld/jw-08-2001/jw-0803-exceptions.html

See part 2 for exception chaining.

These work especially well with Struts, since you can pull off each
exception in the chain and convert it to an ActionError. If you are
wrapping low-level exceptions in higher level business tier exceptions,
then you end up with a general explanation followed by the lower level
cause. So the user's get what they want, and the techs get the detail
they need.


-- Ted Husted, Husted dot Com, Fairport NY US
-- Developing Java Web Applications with Struts
-- Tel: +1 585 737-3463
-- Web: http://husted.com/about/services

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: RES: handling exceptions

[Cakalic, James]

Just to clarify one step further, while Sun _does_ release JDK ports for x86
Linux, that is not the _only_ platform on which Linux runs. Linux is also
available on:

Alpha (DEC)
ARM
Hitachi SuperH
HP PA-RISC
IBM iSeries (aka AS/400)
IBM zSeries
IBM S/390
MIPS (DEC, SGI and others)
Motorola 68K (Atari, Amiga, Mac)
PowerPC (IBM pSeries, PowerMac)
Sun SPARC
Transmeta

IBM's port of Linux to its mini and mainframe lines is actually quite
promising. But Sun doesn't support it with a JDK release. IBM will no doubt
do this just as it has with it's other hardware platforms. But I doubt that
such releases will occur concurrently with Sun's JDK releases -- given the
historical track record.

Jim

> -Original Message-
> From: Calvin Yu [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 28, 2002 2:40 PM
> To: Struts Users Mailing List
> Subject: RE: RES: handling exceptions
> 
> 
> At 11:04 AM 1/28/2002 -0500, you wrote:
> >Aside from functional differences, it is not practical or 
> advisable for
> >everyone to adopt JDK 1.4 as soon as it hits release. For 
> one thing, Sun
> >only releases the JDK for Windows and Solaris platforms. 
> What if you are
> >using Linux? Or AIX? Or HP-UX? Or AS/400?
> 
> I believe that since 1.3.1, Sun has release of their latest 
> JDK's to the 
> Windows, Solaris, and *Linux* platforms simultaneously.  Just a small 
> clarification.
> 
> Calvin
> 
> 
> _
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
> 
> 
> --
> To unsubscribe, e-mail:   
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>


Confidentiality Warning:  This e-mail contains information intended 
only for the use of the individual or entity named above.  If the reader of this 
e-mail is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, any dissemination, publication or copying of 
this e-mail is strictly prohibited. The sender does not accept any responsibility for 
any loss, disruption or damage to your data or computer system that may occur while 
using data contained in, or transmitted with, this e-mail.   If you have received this 
e-mail in error, please immediately notify us by return e-mail.  Thank you.

RE: RES: handling exceptions

[Calvin Yu]

At 11:04 AM 1/28/2002 -0500, you wrote:
>Aside from functional differences, it is not practical or advisable for
>everyone to adopt JDK 1.4 as soon as it hits release. For one thing, Sun
>only releases the JDK for Windows and Solaris platforms. What if you are
>using Linux? Or AIX? Or HP-UX? Or AS/400?

I believe that since 1.3.1, Sun has release of their latest JDK's to the 
Windows, Solaris, and *Linux* platforms simultaneously.  Just a small 
clarification.

Calvin


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: RES: handling exceptions

[Pete Carapetyan]

"Cakalic, James" wrote:

> Hmm. Just because it appears in the JDK doesn't mean that it is a "good
> thing".



> As a user of Struts, imagine
> for a moment that JDK 1.5 included an MVC implementation similar to Struts
> but with reduced functionality and limited extension capability. Would you
> switch just because it was included in the JDK?

Good example ! Any code base that implements another code base is, by definition, 
limited and frozen in time, as a requirement of implementing it.

For example, as much as I enjoy the productivity of Expresso, as a Struts 
implementation it is a 1.0, or whatever version the contributors implement for that 
release of Expresso that I am using at the time. :(

Another example is SOAP, which I would like to use one of Apache's versions. But 
without all the potential parser conflicts worked out between versions of SOAP, 
Tomcat, Xerces, etc, it can be a challenge. So I am trying Apache XmlRpc instead, for 
the moment.

The blessings of a wealth of open source tools.. Really makes one consider the way 
Jboss has used JMX to keep the interfaces all clean.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: RES: handling exceptions

[Jonathan Gibbons]

I agree choice is good.  And Apache Jakarta is one (if not THE) best of them.  JBoss 
is pretty dang fine too.

Hats off.

I also know that the recruiting marketplace tends to focus on core libs.  Loads of 
projects steer clear of
jakarta stuff BECAUSE it is free and open source.  I guess my point of view is that it 
does come down to choice.
You must look at the core API's and offerings and you must be aware of how they are 
evolving.

I will personally tend to either write my own or go with the sun libs.   This is a 
time problem.   Open source teams are
bright, motivated and produce tons of code that is often not well documented.   They 
exert presure on the industry, and
I think it's great they do so.  But I will choose the core libs, simply because the 
next job is more likely to use the core
libs.

Log4j will rapidly change from the only offering, to yet another proprietary (yes I 
know, think recruiting person) lib.  IMHO.
It's not religion, it's choice!  :)

Jonathan



 Message History 



From: "Cakalic, James" <[EMAIL PROTECTED]> on 28/01/2002 11:04 EST

Please respond to "Struts Users Mailing List" <[EMAIL PROTECTED]>

To:   "'Struts Users Mailing List'" <[EMAIL PROTECTED]>
cc:
Subject:  RE: RES: handling exceptions


Hmm. Just because it appears in the JDK doesn't mean that it is a "good
thing". The original JSR47 has changed substantially from its original
specification due, in no small part, to the efforts of the log4j community.
Even so, its current incarnation still pales in comparison to log4j. You
might take time to read the criticism of log4j authors and supporters at
http://jakarta.apache.org/log4j/docs/srtw.html. The Apache Software
Foundation -- you know they host the Jakarta project which includes Struts
and log4j, right? -- does not support the JSR. As a user of Struts, imagine
for a moment that JDK 1.5 included an MVC implementation similar to Struts
but with reduced functionality and limited extension capability. Would you
switch just because it was included in the JDK?

Aside from functional differences, it is not practical or advisable for
everyone to adopt JDK 1.4 as soon as it hits release. For one thing, Sun
only releases the JDK for Windows and Solaris platforms. What if you are
using Linux? Or AIX? Or HP-UX? Or AS/400? Or any of the other plethora of
platforms which Sun does _not_ support? You'll have to wait for vendor
implementations which could be months after the JDK release. As developers
of application-server based software, most of us are also sensitive to the
period of time it takes for the server vendors to support a new JDK. This
was rather substantial between 1.2 and 1.3. I'm not optimistic about 1.4.

I can't comment on the nested exceptions of 1.4 as I haven't really looked
at this. But I would venture that my above comments apply there equally.

Part of the benefit of a large and active open source community is that
there are multiple solutions to every problem. We are able to evaluate the
alternatives and choose a package that most closely meets our needs.
Ultimately, one of these solutions may bubble to the top. But that solution
won't always show up in the next JDK. And even if it does, that doesn't mean
that it then becomes the _only_ solution for the entire community. Choice is
a "good thing".

Best regards,
Jim Cakalic


> -Original Message-
> From: Jonathan Gibbons [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 28, 2002 7:30 AM
> To: Struts Users Mailing List
> Subject: Re: RES: handling exceptions
>
>
>
> Hi,
>
> JDK1.4 is at final release candidate stage.   They include
> nested exceptions (including all remote exceptions) and a
> logging framework.
> Use these, and not any other version (eg log4j), you will be
> future proofing your CV and code.
>
> Jonathan
> ===
> For EJB and Struts code generators see:
> http://www.faraway.co.uk/tallsoft/lowroad/
>
>  Message History
> 
>
>
> From: Chuck Cavaness <[EMAIL PROTECTED]> on
> 28/01/2002 08:22 EST
>
> Please respond to "Struts Users Mailing List"
> <[EMAIL PROTECTED]>
>
> To:   "Struts Users Mailing List" <[EMAIL PROTECTED]>
> cc:
> Subject:  Re: RES: handling exceptions
>
>
> Unfortunately no because I think it contains some really nice
> features for
> Struts. This is a commerical product that I'm working on.
> However, I have
> received permission to discuss the exception framework in the
> Struts book
> that I'm working on for OReilly right now. Search the mailing
> list archives
> for the thread &quo

RE: RES: handling exceptions

[Cakalic, James]

Hmm. Just because it appears in the JDK doesn't mean that it is a "good
thing". The original JSR47 has changed substantially from its original
specification due, in no small part, to the efforts of the log4j community.
Even so, its current incarnation still pales in comparison to log4j. You
might take time to read the criticism of log4j authors and supporters at
http://jakarta.apache.org/log4j/docs/srtw.html. The Apache Software
Foundation -- you know they host the Jakarta project which includes Struts
and log4j, right? -- does not support the JSR. As a user of Struts, imagine
for a moment that JDK 1.5 included an MVC implementation similar to Struts
but with reduced functionality and limited extension capability. Would you
switch just because it was included in the JDK?

Aside from functional differences, it is not practical or advisable for
everyone to adopt JDK 1.4 as soon as it hits release. For one thing, Sun
only releases the JDK for Windows and Solaris platforms. What if you are
using Linux? Or AIX? Or HP-UX? Or AS/400? Or any of the other plethora of
platforms which Sun does _not_ support? You'll have to wait for vendor
implementations which could be months after the JDK release. As developers
of application-server based software, most of us are also sensitive to the
period of time it takes for the server vendors to support a new JDK. This
was rather substantial between 1.2 and 1.3. I'm not optimistic about 1.4. 

I can't comment on the nested exceptions of 1.4 as I haven't really looked
at this. But I would venture that my above comments apply there equally.

Part of the benefit of a large and active open source community is that
there are multiple solutions to every problem. We are able to evaluate the
alternatives and choose a package that most closely meets our needs.
Ultimately, one of these solutions may bubble to the top. But that solution
won't always show up in the next JDK. And even if it does, that doesn't mean
that it then becomes the _only_ solution for the entire community. Choice is
a "good thing".

Best regards,
Jim Cakalic


> -Original Message-
> From: Jonathan Gibbons [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 28, 2002 7:30 AM
> To: Struts Users Mailing List
> Subject: Re: RES: handling exceptions
> 
> 
> 
> Hi,
> 
> JDK1.4 is at final release candidate stage.   They include 
> nested exceptions (including all remote exceptions) and a 
> logging framework.
> Use these, and not any other version (eg log4j), you will be 
> future proofing your CV and code.
> 
> Jonathan
> ===
> For EJB and Struts code generators see:
> http://www.faraway.co.uk/tallsoft/lowroad/
> 
>  Message History 
> 
> 
> 
> From: Chuck Cavaness <[EMAIL PROTECTED]> on 
> 28/01/2002 08:22 EST
> 
> Please respond to "Struts Users Mailing List" 
> <[EMAIL PROTECTED]>
> 
> To:   "Struts Users Mailing List" <[EMAIL PROTECTED]>
> cc:
> Subject:  Re: RES: handling exceptions
> 
> 
> Unfortunately no because I think it contains some really nice 
> features for
> Struts. This is a commerical product that I'm working on. 
> However, I have
> received permission to discuss the exception framework in the 
> Struts book
> that I'm working on for OReilly right now. Search the mailing 
> list archives
> for the thread "OReilly Struts Book".
> 
> Chuck
> 
> 
> At 11:02 AM 1/28/2002 -0200, you wrote:
> >Thanks.
> >I want to know if your framework of handling exception will 
> be opensource,
> >like struts.
> >
> >
> >-Mensagem original-
> >De: Chuck Cavaness [mailto:[EMAIL PROTECTED]]
> >Enviada em: segunda-feira, 28 de janeiro de 2002 10:27
> >Para: Struts Users Mailing List
> >Assunto: Re: handling exceptions
> >
> >
> >We've developed a pretty eloborate exception handling framework on my
> >current project. We're using EJB on the backend, so
> >we must also deal with remote type exceptions. First we catorgize
> >exceptions into those that the user can recover from and 
> those that they
> >can't. Sort of like fatal and non-fatal. You also need to 
> divide exceptions
> >into system and application exceptions. System exceptions 
> are ones like
> >remote exception, or maybe some type of datastore exception. 
> Application
> >exceptions for us are ones like required fields were missing 
> or duplicate
> >values for a unique column. In our world, the same exception 
> framework has
> >to work for ERP systems, so it's not just the web container.
> >
> >Anyway, for those

RE: RES: handling exceptions

[Jonathan Gibbons]

Well, since Tomcat (for instance) runs the JVM you install then you get the logging 
and exception stuff as soon as you install 1.4,

You do NOT get it within the tomcat code, but you do within your own code.  i.e. if 
their stuff fails then you won't see it.  But if your stuff fails, or logs then you 
get it as
soon as you use JDK1.4  (I have yet to use it in anger, I must admit - probably for 
the reason you just stated :)

Jonathan

Want to write your code as if you used EJB, but you don't?   Visit:
http://www.faraway.co.uk/tallsoft/lowroad/


 Message History 



From: "Mark Galbreath" <[EMAIL PROTECTED]> on 28/01/2002 09:52 EST

Please respond to "Struts Users Mailing List" <[EMAIL PROTECTED]>

To:   "'Struts Users Mailing List'" <[EMAIL PROTECTED]>
cc:
Subject:  RE: RES: handling exceptions


That's all very good (and I especially like the inclusion of the RegExp
class in 1.4) but when will we have servlet and app containers that can
support with 1.4?

Mark

-Original Message-
From: Jonathan Gibbons [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 28, 2002 8:30 AM
To: Struts Users Mailing List
Subject: Re: RES: handling exceptions



Hi,

JDK1.4 is at final release candidate stage.   They include nested exceptions
(including all remote exceptions) and a logging framework.
Use these, and not any other version (eg log4j), you will be future proofing
your CV and code.

Jonathan
===
For EJB and Struts code generators see:
http://www.faraway.co.uk/tallsoft/lowroad/

 Message
History 


From: Chuck Cavaness <[EMAIL PROTECTED]> on 28/01/2002 08:22 EST

Please respond to "Struts Users Mailing List"
<[EMAIL PROTECTED]>

To:   "Struts Users Mailing List" <[EMAIL PROTECTED]>
cc:
Subject:  Re: RES: handling exceptions


Unfortunately no because I think it contains some really nice features for
Struts. This is a commerical product that I'm working on. However, I have
received permission to discuss the exception framework in the Struts book
that I'm working on for OReilly right now. Search the mailing list archives
for the thread "OReilly Struts Book".

Chuck


At 11:02 AM 1/28/2002 -0200, you wrote:
>Thanks.
>I want to know if your framework of handling exception will be opensource,
>like struts.
>
>
>-Mensagem original-
>De: Chuck Cavaness [mailto:[EMAIL PROTECTED]]
>Enviada em: segunda-feira, 28 de janeiro de 2002 10:27
>Para: Struts Users Mailing List
>Assunto: Re: handling exceptions
>
>
>We've developed a pretty eloborate exception handling framework on my
>current project. We're using EJB on the backend, so
>we must also deal with remote type exceptions. First we catorgize
>exceptions into those that the user can recover from and those that they
>can't. Sort of like fatal and non-fatal. You also need to divide exceptions
>into system and application exceptions. System exceptions are ones like
>remote exception, or maybe some type of datastore exception. Application
>exceptions for us are ones like required fields were missing or duplicate
>values for a unique column. In our world, the same exception framework has
>to work for ERP systems, so it's not just the web container.
>
>Anyway, for those exceptions that the user can recover from like "required
>fields missing", we catch those type of exceptions, create an ActionError
>with a message from the bundle specifically for that exception, and then
>forward back to the input page. This gives the user a chance to fix the
>problem and resubmit. For the more severe exceptions, we also catch those
>and forward to a "system-error" type page since there's probably nothing
>you can do about it anyway. We use an abstract base action that all of our
>actions extend. We have all of this behavior in the base action and none of
>the action classes have to worry about catching these exceptions. The
>abstract base action implements the perform and has an abstract doWork type
>method. The doWork method is wrapped with the try catch blocks. Each
>concreate action class implements the doWork and doesn't have to worry
>about the try catch.
>
>I hope that gives you some ideas.
>
>chuck
>
>p.s. Regarding your other post about using System.out in your action
>classes; I wouldn't recommend that approach. Use log4j instead. That way,
>you can shut off the debug logging externally by just editing the
>log4j.properties file.
>
>At 09:50 AM 1/28/2002 -0200, you wrote:
> >Could somebody help me ?
> >
> >I have to many pr

RE: RES: handling exceptions

[Mark Galbreath]

That's all very good (and I especially like the inclusion of the RegExp
class in 1.4) but when will we have servlet and app containers that can
support with 1.4?

Mark

-Original Message-
From: Jonathan Gibbons [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 28, 2002 8:30 AM
To: Struts Users Mailing List
Subject: Re: RES: handling exceptions



Hi,

JDK1.4 is at final release candidate stage.   They include nested exceptions
(including all remote exceptions) and a logging framework.
Use these, and not any other version (eg log4j), you will be future proofing
your CV and code.

Jonathan
===
For EJB and Struts code generators see:
http://www.faraway.co.uk/tallsoft/lowroad/

 Message
History 


From: Chuck Cavaness <[EMAIL PROTECTED]> on 28/01/2002 08:22 EST

Please respond to "Struts Users Mailing List"
<[EMAIL PROTECTED]>

To:   "Struts Users Mailing List" <[EMAIL PROTECTED]>
cc:
Subject:  Re: RES: handling exceptions


Unfortunately no because I think it contains some really nice features for
Struts. This is a commerical product that I'm working on. However, I have
received permission to discuss the exception framework in the Struts book
that I'm working on for OReilly right now. Search the mailing list archives
for the thread "OReilly Struts Book".

Chuck


At 11:02 AM 1/28/2002 -0200, you wrote:
>Thanks.
>I want to know if your framework of handling exception will be opensource,
>like struts.
>
>
>-Mensagem original-
>De: Chuck Cavaness [mailto:[EMAIL PROTECTED]]
>Enviada em: segunda-feira, 28 de janeiro de 2002 10:27
>Para: Struts Users Mailing List
>Assunto: Re: handling exceptions
>
>
>We've developed a pretty eloborate exception handling framework on my
>current project. We're using EJB on the backend, so
>we must also deal with remote type exceptions. First we catorgize
>exceptions into those that the user can recover from and those that they
>can't. Sort of like fatal and non-fatal. You also need to divide exceptions
>into system and application exceptions. System exceptions are ones like
>remote exception, or maybe some type of datastore exception. Application
>exceptions for us are ones like required fields were missing or duplicate
>values for a unique column. In our world, the same exception framework has
>to work for ERP systems, so it's not just the web container.
>
>Anyway, for those exceptions that the user can recover from like "required
>fields missing", we catch those type of exceptions, create an ActionError
>with a message from the bundle specifically for that exception, and then
>forward back to the input page. This gives the user a chance to fix the
>problem and resubmit. For the more severe exceptions, we also catch those
>and forward to a "system-error" type page since there's probably nothing
>you can do about it anyway. We use an abstract base action that all of our
>actions extend. We have all of this behavior in the base action and none of
>the action classes have to worry about catching these exceptions. The
>abstract base action implements the perform and has an abstract doWork type
>method. The doWork method is wrapped with the try catch blocks. Each
>concreate action class implements the doWork and doesn't have to worry
>about the try catch.
>
>I hope that gives you some ideas.
>
>chuck
>
>p.s. Regarding your other post about using System.out in your action
>classes; I wouldn't recommend that approach. Use log4j instead. That way,
>you can shut off the debug logging externally by just editing the
>log4j.properties file.
>
>At 09:50 AM 1/28/2002 -0200, you wrote:
> >Could somebody help me ?
> >
> >I have to many problems with handling exception of the Struts.
> >what do you suggest to handling exception of the deployment applications?
> >
> >--
> >To unsubscribe, e-mail:
><mailto:[EMAIL PROTECTED]>
> >For additional commands, e-mail:
><mailto:[EMAIL PROTECTED]>
>
>
>--
>To unsubscribe, e-mail:
><mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail:
><mailto:[EMAIL PROTECTED]>
>
>
>
>
>--
>To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>


--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>






--

This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.



--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: handling exceptions

[Mark Galbreath]

How do you differentiate between these exceptions (throws, throw new, catch)
in the JavaDocs?

Mark

-Original Message-
From: Chuck Cavaness [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 28, 2002 7:27 AM
To: Struts Users Mailing List
Subject: Re: handling exceptions


We've developed a pretty eloborate exception handling framework on my
current project. We're using EJB on the backend, so


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: RES: handling exceptions

[Chuck Cavaness]

That's a good idea. The only issue that I can think of is that you'll be dependent on 
1.4, since the logging API isn't available to previous SDKs. Something like log4j is 
available to 1.1 and above. There's no reason that I can think of why anyone wouldn't 
use the latest version of the SDK, but I'm not sure everyone will switch immediately.

Chuck
--
Sent via jApache.org

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: RES: handling exceptions

[Jonathan Gibbons]

Hi,

JDK1.4 is at final release candidate stage.   They include nested exceptions 
(including all remote exceptions) and a logging framework.
Use these, and not any other version (eg log4j), you will be future proofing your CV 
and code.

Jonathan
===
For EJB and Struts code generators see:
http://www.faraway.co.uk/tallsoft/lowroad/

 Message History 



From: Chuck Cavaness <[EMAIL PROTECTED]> on 28/01/2002 08:22 EST

Please respond to "Struts Users Mailing List" <[EMAIL PROTECTED]>

To:   "Struts Users Mailing List" <[EMAIL PROTECTED]>
cc:
Subject:  Re: RES: handling exceptions


Unfortunately no because I think it contains some really nice features for
Struts. This is a commerical product that I'm working on. However, I have
received permission to discuss the exception framework in the Struts book
that I'm working on for OReilly right now. Search the mailing list archives
for the thread "OReilly Struts Book".

Chuck


At 11:02 AM 1/28/2002 -0200, you wrote:
>Thanks.
>I want to know if your framework of handling exception will be opensource,
>like struts.
>
>
>-Mensagem original-
>De: Chuck Cavaness [mailto:[EMAIL PROTECTED]]
>Enviada em: segunda-feira, 28 de janeiro de 2002 10:27
>Para: Struts Users Mailing List
>Assunto: Re: handling exceptions
>
>
>We've developed a pretty eloborate exception handling framework on my
>current project. We're using EJB on the backend, so
>we must also deal with remote type exceptions. First we catorgize
>exceptions into those that the user can recover from and those that they
>can't. Sort of like fatal and non-fatal. You also need to divide exceptions
>into system and application exceptions. System exceptions are ones like
>remote exception, or maybe some type of datastore exception. Application
>exceptions for us are ones like required fields were missing or duplicate
>values for a unique column. In our world, the same exception framework has
>to work for ERP systems, so it's not just the web container.
>
>Anyway, for those exceptions that the user can recover from like "required
>fields missing", we catch those type of exceptions, create an ActionError
>with a message from the bundle specifically for that exception, and then
>forward back to the input page. This gives the user a chance to fix the
>problem and resubmit. For the more severe exceptions, we also catch those
>and forward to a "system-error" type page since there's probably nothing
>you can do about it anyway. We use an abstract base action that all of our
>actions extend. We have all of this behavior in the base action and none of
>the action classes have to worry about catching these exceptions. The
>abstract base action implements the perform and has an abstract doWork type
>method. The doWork method is wrapped with the try catch blocks. Each
>concreate action class implements the doWork and doesn't have to worry
>about the try catch.
>
>I hope that gives you some ideas.
>
>chuck
>
>p.s. Regarding your other post about using System.out in your action
>classes; I wouldn't recommend that approach. Use log4j instead. That way,
>you can shut off the debug logging externally by just editing the
>log4j.properties file.
>
>At 09:50 AM 1/28/2002 -0200, you wrote:
> >Could somebody help me ?
> >
> >I have to many problems with handling exception of the Struts.
> >what do you suggest to handling exception of the deployment applications?
> >
> >--
> >To unsubscribe, e-mail:
><mailto:[EMAIL PROTECTED]>
> >For additional commands, e-mail:
><mailto:[EMAIL PROTECTED]>
>
>
>--
>To unsubscribe, e-mail:
><mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail:
><mailto:[EMAIL PROTECTED]>
>
>
>
>
>--
>To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>






--

This e-mail may contain confidential and/or privileged information. If you are not the 
intended recipient (or have received this e-mail in error) please notify the sender 
immediately and destroy this e-mail. Any unauthorized copying, disclosure or 
distribution of the material in this e-mail is strictly forbidden.



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: RES: handling exceptions

[Chuck Cavaness]

Unfortunately no because I think it contains some really nice features for 
Struts. This is a commerical product that I'm working on. However, I have 
received permission to discuss the exception framework in the Struts book 
that I'm working on for OReilly right now. Search the mailing list archives 
for the thread "OReilly Struts Book".

Chuck


At 11:02 AM 1/28/2002 -0200, you wrote:
>Thanks.
>I want to know if your framework of handling exception will be opensource,
>like struts.
>
>
>-Mensagem original-
>De: Chuck Cavaness [mailto:[EMAIL PROTECTED]]
>Enviada em: segunda-feira, 28 de janeiro de 2002 10:27
>Para: Struts Users Mailing List
>Assunto: Re: handling exceptions
>
>
>We've developed a pretty eloborate exception handling framework on my
>current project. We're using EJB on the backend, so
>we must also deal with remote type exceptions. First we catorgize
>exceptions into those that the user can recover from and those that they
>can't. Sort of like fatal and non-fatal. You also need to divide exceptions
>into system and application exceptions. System exceptions are ones like
>remote exception, or maybe some type of datastore exception. Application
>exceptions for us are ones like required fields were missing or duplicate
>values for a unique column. In our world, the same exception framework has
>to work for ERP systems, so it's not just the web container.
>
>Anyway, for those exceptions that the user can recover from like "required
>fields missing", we catch those type of exceptions, create an ActionError
>with a message from the bundle specifically for that exception, and then
>forward back to the input page. This gives the user a chance to fix the
>problem and resubmit. For the more severe exceptions, we also catch those
>and forward to a "system-error" type page since there's probably nothing
>you can do about it anyway. We use an abstract base action that all of our
>actions extend. We have all of this behavior in the base action and none of
>the action classes have to worry about catching these exceptions. The
>abstract base action implements the perform and has an abstract doWork type
>method. The doWork method is wrapped with the try catch blocks. Each
>concreate action class implements the doWork and doesn't have to worry
>about the try catch.
>
>I hope that gives you some ideas.
>
>chuck
>
>p.s. Regarding your other post about using System.out in your action
>classes; I wouldn't recommend that approach. Use log4j instead. That way,
>you can shut off the debug logging externally by just editing the
>log4j.properties file.
>
>At 09:50 AM 1/28/2002 -0200, you wrote:
> >Could somebody help me ?
> >
> >I have to many problems with handling exception of the Struts.
> >what do you suggest to handling exception of the deployment applications?
> >
> >--
> >To unsubscribe, e-mail:
><mailto:[EMAIL PROTECTED]>
> >For additional commands, e-mail:
><mailto:[EMAIL PROTECTED]>
>
>
>--
>To unsubscribe, e-mail:
><mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail:
><mailto:[EMAIL PROTECTED]>
>
>
>
>
>--
>To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RES: handling exceptions

[Rubens Gama]

Thanks.
I want to know if your framework of handling exception will be opensource,
like struts.


-Mensagem original-
De: Chuck Cavaness [mailto:[EMAIL PROTECTED]]
Enviada em: segunda-feira, 28 de janeiro de 2002 10:27
Para: Struts Users Mailing List
Assunto: Re: handling exceptions


We've developed a pretty eloborate exception handling framework on my
current project. We're using EJB on the backend, so
we must also deal with remote type exceptions. First we catorgize
exceptions into those that the user can recover from and those that they
can't. Sort of like fatal and non-fatal. You also need to divide exceptions
into system and application exceptions. System exceptions are ones like
remote exception, or maybe some type of datastore exception. Application
exceptions for us are ones like required fields were missing or duplicate
values for a unique column. In our world, the same exception framework has
to work for ERP systems, so it's not just the web container.

Anyway, for those exceptions that the user can recover from like "required
fields missing", we catch those type of exceptions, create an ActionError
with a message from the bundle specifically for that exception, and then
forward back to the input page. This gives the user a chance to fix the
problem and resubmit. For the more severe exceptions, we also catch those
and forward to a "system-error" type page since there's probably nothing
you can do about it anyway. We use an abstract base action that all of our
actions extend. We have all of this behavior in the base action and none of
the action classes have to worry about catching these exceptions. The
abstract base action implements the perform and has an abstract doWork type
method. The doWork method is wrapped with the try catch blocks. Each
concreate action class implements the doWork and doesn't have to worry
about the try catch.

I hope that gives you some ideas.

chuck

p.s. Regarding your other post about using System.out in your action
classes; I wouldn't recommend that approach. Use log4j instead. That way,
you can shut off the debug logging externally by just editing the
log4j.properties file.

At 09:50 AM 1/28/2002 -0200, you wrote:
>Could somebody help me ?
>
>I have to many problems with handling exception of the Struts.
>what do you suggest to handling exception of the deployment applications?
>
>--
>To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>


--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: handling exceptions

[Chuck Cavaness]

We've developed a pretty eloborate exception handling framework on my 
current project. We're using EJB on the backend, so
we must also deal with remote type exceptions. First we catorgize 
exceptions into those that the user can recover from and those that they 
can't. Sort of like fatal and non-fatal. You also need to divide exceptions 
into system and application exceptions. System exceptions are ones like 
remote exception, or maybe some type of datastore exception. Application 
exceptions for us are ones like required fields were missing or duplicate 
values for a unique column. In our world, the same exception framework has 
to work for ERP systems, so it's not just the web container.

Anyway, for those exceptions that the user can recover from like "required 
fields missing", we catch those type of exceptions, create an ActionError 
with a message from the bundle specifically for that exception, and then 
forward back to the input page. This gives the user a chance to fix the 
problem and resubmit. For the more severe exceptions, we also catch those 
and forward to a "system-error" type page since there's probably nothing 
you can do about it anyway. We use an abstract base action that all of our 
actions extend. We have all of this behavior in the base action and none of 
the action classes have to worry about catching these exceptions. The 
abstract base action implements the perform and has an abstract doWork type 
method. The doWork method is wrapped with the try catch blocks. Each 
concreate action class implements the doWork and doesn't have to worry 
about the try catch.

I hope that gives you some ideas.

chuck

p.s. Regarding your other post about using System.out in your action 
classes; I wouldn't recommend that approach. Use log4j instead. That way, 
you can shut off the debug logging externally by just editing the 
log4j.properties file.

At 09:50 AM 1/28/2002 -0200, you wrote:
>Could somebody help me ?
>
>I have to many problems with handling exception of the Struts.
>what do you suggest to handling exception of the deployment applications?
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Handling Exceptions with Struts

[Rubens Gama]

To debug my Action classes, i use a method call "System.out.println()" or
"servlet.log()"...
is it a good practice?


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

handling exceptions

[Rubens Gama]

Could somebody help me ?

I have to many problems with handling exception of the Struts.
what do you suggest to handling exception of the deployment applications?

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Handling exceptions thrown from Action.perform in the errorpage?

[Ted Husted]

>   
> 
>   

> return mapping.findForward("error")

Will forward to the file named "errorpage.jsp" in the root of your Web
application. 

If it doesn't, something else is wrong, like doPerform is not throwing
the exception (Try logging it too.), or the page is in the root of your
container instead, et cetera.

Meanwhile, when saving exceptions for display on a JSP, you might use 

Action.EXCEPTION_KEY

for the attribute key. The custom tags use this, and so your page would
also display any exceptions the tags throw. (See saveException() in
util.RequestUtils)

[EMAIL PROTECTED] wrote:
> 
> Hey there!
> 
> I have a question for you guys.
> 
> When an exception is thrown in my Action derivative I want that exception
> to
> be handled by the errorpage (<%@ page isErrorPage="true %>). After fooling
> around
> with the web.xml file adding entries such as:
> 
>  
>   javax.servlet.ServletException
>   /errorpage.jsp
>  
> 
> the result is that when I throw a ServletException from the Action.perform
> method
> I'm directed to my login page(?!). I've tried using the
> "mapping.findForward" approach,
> as in:
> 
> public final ActionForward perform(ActionMapping mapping, ActionForm form,
> HttpServletRequest request, HttpServletResponse response)
> throws IOException, ServletException
> {
>  ActionForward af = null;
> 
>  try {
>   af = doPerform(...); // throws exception
>  } catch(Throwable t) {
>   request.setAttribute("javax.servlet.jsp.jspException", new
> ServletException(t));
>   af = mapping.findForward("error");
>  }
> 
> return af;
> }
> 
> ofcourse, I added:
> 
>   
>   
> 
>   
> 
> to the struts-config.xml file.
> 
> That didn't work either. The only approach that seems to work for me is:
> 
> public final ActionForward perform(ActionMapping mapping, ActionForm form,
> HttpServletRequest request, HttpServletResponse response)
> throws IOException, ServletException
> {
>  try {
>   return doPerform(...); // throws exception
>  } catch(Throwable t) {
>   request.setAttribute("javax.servlet.jsp.jspException", t);
>   getServlet().getServletContext().getRequestDispatcher
> ("/errorpage.jsp").forward(request, response);
>  }
> }
> 
> Now my questions are:
> 
>  Is this last approach safe to use with Struts?
>  How do you guys accomplish this? Do you use a different approach
> altogether?
> 
> TIA,
> S. Bro

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 737-3463.
-- http://www.husted.com/about/struts/

Handling exceptions thrown from Action.perform in the errorpage?

[sbt]

Hey there!

I have a question for you guys.

When an exception is thrown in my Action derivative I want that exception
to
be handled by the errorpage (<%@ page isErrorPage="true %>). After fooling
around
with the web.xml file adding entries such as:

 
  javax.servlet.ServletException
  /errorpage.jsp
 

the result is that when I throw a ServletException from the Action.perform
method
I'm directed to my login page(?!). I've tried using the
"mapping.findForward" approach,
as in:

public final ActionForward perform(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException
{
 ActionForward af = null;

 try {
  af = doPerform(...); // throws exception
 } catch(Throwable t) {
  request.setAttribute("javax.servlet.jsp.jspException", new
ServletException(t));
  af = mapping.findForward("error");
 }


return af;
}

ofcourse, I added:

  
  

  

to the struts-config.xml file.


That didn't work either. The only approach that seems to work for me is:



public final ActionForward perform(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException
{
 try {
  return doPerform(...); // throws exception
 } catch(Throwable t) {
  request.setAttribute("javax.servlet.jsp.jspException", t);
  getServlet().getServletContext().getRequestDispatcher
("/errorpage.jsp").forward(request, response);
 }
}


Now my questions are:

 Is this last approach safe to use with Struts?
 How do you guys accomplish this? Do you use a different approach
altogether?

TIA,
S. Bro