You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by "Carter, Steve" <SC...@swiftrivers.com> on 2002/02/20 18:08:49 UTC
action and form contract
On husted.com, Ted Husted wrote:
Do not check for null ActionForm beans in your Actions
If an Action expects an ActionForm bean, then its API contact with the ActionMappings should require that this bean, or a subclass, be named in the ActionMapping. The Actions contact wit the controller is that it will always instantiate the bean before the Action is called. If either contact is broken, the application should expose a null pointer exception so that the problem is fixed and the misunderstanding resolved. Whether an Action expects an ActionForm bean should be specified in its Javadoc.
Now I'm wondering if 'contact' was a type and what he meant was 'contract', that is, in the sense of an API contract or implied constrain, pre-condition.
(You out there Ted?)
Anyway, this seems like a good idea. I'm always complaining that exceptions are often overused or misused in Java, and this seems like a good use: let the exception raise havoc, in order to inform you of a really exceptional condition, and one that should be exposed if it exists.
Steve Carter
Sr. Software Engineer
Swift Rivers
scarter@swiftrivers.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: action and form contract
Posted by Ted Husted <hu...@apache.org>.
How about this:
Do not blindly check for null ActionForm beans in all your Actions
If an Action expects an ActionForm bean, then its API contact with the
ActionMappings should require that a particular ActionForm bean, or
subclass thereof, be named in the ActionMapping. The Action's contract
with the controller is that it will always instantiate the bean before
the Action is called. If either contract is broken, the application
should expose a null pointer exception so that the programming error is
fixed and the misunderstanding resolved. Whether an Action expects an
ActionForm bean should be specified in its Javadoc.
Alternatively, the perform method should provide a general check of all
its preconditions, including, but not limited to, the existance of an
ActionForm bean.
Do check for essential preconditions in your Actions
The perform method in the Action is a key hotspot in the framework, and
may be realizing several different API contracts. To be sure all the
contracts are being met, provide a general error catching routine for
your Actions. This can look for any number of preconditions including
whether there is a form bean when one is expected, and whether it is of
the requesite class, and provide the appropriate error messages.
See the SuperAction class in the Scaffolding package for a working
example. Scaffolding can be found in the Contrib folder of the nightly
build.
-- 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
"Carter, Steve" wrote:
>
> On husted.com, Ted Husted wrote:
> Do not check for null ActionForm beans in your Actions
> If an Action expects an ActionForm bean, then its API contact with the ActionMappings should require that this bean, or a subclass, be named in the ActionMapping. The Actions contact wit the controller is that it will always instantiate the bean before the Action is called. If either contact is broken, the application should expose a null pointer exception so that the problem is fixed and the misunderstanding resolved. Whether an Action expects an ActionForm bean should be specified in its Javadoc.
>
> Now I'm wondering if 'contact' was a type and what he meant was 'contract', that is, in the sense of an API contract or implied constrain, pre-condition.
>
> (You out there Ted?)
>
> Anyway, this seems like a good idea. I'm always complaining that exceptions are often overused or misused in Java, and this seems like a good use: let the exception raise havoc, in order to inform you of a really exceptional condition, and one that should be exposed if it exists.
>
> Steve Carter
> Sr. Software Engineer
> Swift Rivers
> scarter@swiftrivers.com
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: action and form contract
Posted by keithBacon <ke...@yahoo.com>.
I've often wondered what other people do for this sort of thing.
Here's my style for constructive comment. (no insults please!).
I'm trying to write code that can run for 10 years & be easy to maintain.
==================
1 - Handling form pointer null -
My preferred style in perform method is below.
The comment is in the 'reference' code - ie. the best example
to be used as a model for other code. Not that I totally
stick to it - but wish I did!
Maybe overkill but I try to code for
1 - Robustness/Defensiveness. Help people when they misuse your program.
2 - An error has 1 cause & that cause is obvious.
3 - De-skill troubleshooting/problem fixing.
/*
* ClassCastException or NullPointerException is caused by
* a struts-config.xml set-up error or a bug.
* (This comment for reference code only - remove in copied code)
*/
LinkListForm thisForm = (LinkListForm) form;
=======================
2 - Exception handling.
Often it's not enough to let a NullpointerException do the talking
as above but I validate input data that 'should' be right.
I have my own exception to indicate really obviously that it's raised by my
code not java or something else.
if (linkMaintLinkID == null) {
throw new BiffApplicationException(
"bug in caller - linkMaintID null");
}
int selectedLinkID = 0;
try {
selectedLinkID = Integer.parseInt(linkMaintLinkID);
} catch (NumberFormatException nfe) {
throw new BiffApplicationException(
"bug in caller - linkMaintID not integer: "+
linkMaintID)
}
=====================
3 I use exceptions for technical problems - bugs or
incorrect deployment. But not for user validation errors.
========================
4 - Never hide diagnostic information. (I get excitable about this!).
This code is from ActionServlet.
String value = getServletConfig().getInitParameter("debug");
try {
debug = Integer.parseInt(value);
} catch (Throwable t) {
debug = 0; // <-------
}
I would code this to either throw exceptions or log warnings:-
- ActionServlet: Warning- servlet Init parm: debug not found defaulting to 0
- ActionServlet: Warning- servlet Init parm: debug=qqqq. Not integer. using 0
==========================
--- "Carter, Steve" <SC...@swiftrivers.com> wrote:
> On husted.com, Ted Husted wrote:
> Do not check for null ActionForm beans in your Actions
> If an Action expects an ActionForm bean, then its API contact with the
> ActionMappings should require that this bean, or a subclass, be named in the
> ActionMapping. The Actions contact wit the controller is that it will always
> instantiate the bean before the Action is called. If either contact is
> broken, the application should expose a null pointer exception so that the
> problem is fixed and the misunderstanding resolved. Whether an Action expects
> an ActionForm bean should be specified in its Javadoc.
>
> Now I'm wondering if 'contact' was a type and what he meant was 'contract',
> that is, in the sense of an API contract or implied constrain, pre-condition.
>
> (You out there Ted?)
>
> Anyway, this seems like a good idea. I'm always complaining that exceptions
> are often overused or misused in Java, and this seems like a good use: let
> the exception raise havoc, in order to inform you of a really exceptional
> condition, and one that should be exposed if it exists.
>
>
>
> Steve Carter
> Sr. Software Engineer
> Swift Rivers
> scarter@swiftrivers.com
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
=====
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Search the archive:-
http://www.mail-archive.com/struts-user%40jakarta.apache.org/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Keith Bacon - Looking for struts work - South-East UK.
phone UK 07960 011275
__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>