struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Suarez" <>
Subject RE: Java edit method - design pattern? (O/T)
Date Mon, 04 Oct 2004 15:21:13 GMT
Not sure if I agree with your definition of exception or see how it
conflicts.  There are 2 java exception types, runtime and checked.
These can be loosely translated as "unhandleable" and "handleable" (sort
of)...  Couldn't think of a better word right now...

Anyway, in terms of a business function you have different types of
errors as well.  Errors that the user needs to correct, and warnings
that the user needs to be made aware of.  What I've done in the past is
to create exception types that mirror these cases in the business tier.
Then you can have one translation utility that converts/forwards as
necessary for the exception type.  I have these custom exceptions extend
the checked exception types.  The logic in the utility that runs on the
struts side basically converts the exceptions to messages that will be
displayed in the html:errors area.  In the case of a "bad" exception,
the request is forwarded to an error page.

Since the rendering is specific to struts, the same back-end can throw
the same exceptions elsewhere and they would be handled as needed for
the different front-end.  Hope that makes sense.


-----Original Message-----
From: David G. Friedman [] 
Sent: Sunday, October 03, 2004 10:31 PM
To: Struts Users Mailing List
Subject: RE: Java edit method - design pattern? (O/T)


Could you pass an ActionMessages object as the second parameter to your
method?  That way, you still return your boolean but you could 'push' an
ActioMessage on the ActionMessages 'stack' for display in an error JSP.
you are worried about keeping your business methods separate from
you could pass an empty (but instantiated) (Jakarta commons?) collection
type.  Back in the invoking method, if the boolean is false, you could
iterate through the collection and add those String messages (or
they were that you put into the collection) into ActionMessages for
in your JSP.

I'm eager to see what other solutions are suggested by Struts users.
sure we'll see many different opinions, all quite effective. :)


-----Original Message-----
From: []
Sent: Sunday, October 03, 2004 6:51 PM
To: Struts Users Mailing List
Subject: Java edit method - design pattern? (O/T)

I'm working on an application API to be deployed with struts, and am
interested in how other developers are dealing with 'editing' methods,
methods that answer a question with a true/false value, but if false is
returned, you also want to know why.

for example, a credit card application may have a method 'boolean
allowCreditFor(int cashAmount)' which returns true if the amount
is ok, but false if not.
But what if you want to know why false is returned?

Using an Exception seems to be a pretty good fit, but doesn't seem to me
be in keeping with its purpose (ie that an Exception should signal an
abnormal outcome that couldn't be handled locally).

Thanks for your thoughts,

John Thompson

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

View raw message