Hi Paul! Can you send a sample file? Your workaround
seems interesting.
Regards,
L. Yeung
--- Paul Dillon [EMAIL PROTECTED] wrote:
You need two strategies - one for errors you can
handle and recover from,
and another for everything else.
For errors I can handle (includes exceptions and
I basically do the same thing as Paul. My business objects throw
their own exceptions, which I can catch. These exception classes
are chained and often include more than one message: the initial
cause and my business explanation. I use the ActionError class to
send this to the JSP. Since they
Thanks Ted Paul.
As always, a useful piece of the puzzle.
Just wondering what you need the isCause() method. I
read the article about exception handling, but when
you write the detail message -- won't this write the
cause out for you?
Where would you not have the cause?
Also: the business
Sometimes there is only a business exception, other times there is an
underlying exception followed by a business exception. So the business
object is thrown a SQL error, wraps it, and throws its own version.
Other times, there can be a business logic error that doesn't wrap
anything else.
a combination of 2 and 4 works well. ie, put together ActionErrors, forward
to the page where they are displayed with html:errors/
Of course, you don't have to use ActionErrors - and list will do, but why
not? :)
- Brett
-Original Message-
From: Greg Callaghan [mailto:[EMAIL
You need two strategies - one for errors you can handle and recover from,
and another for everything else.
For errors I can handle (includes exceptions and business-level
validations), I describe the problem in plain english, stick it into a
string attribute on the request object, then I forward
6 matches
Mail list logo
