Inline

Quoting "Craig R. McClanahan" <[EMAIL PROTECTED]>:

> 
> 
> On Fri, 31 Jan 2003, Wendy Smoak wrote:
> 
> > Date: Fri, 31 Jan 2003 10:50:56 -0700
> > From: Wendy Smoak <[EMAIL PROTECTED]>
> > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> > To: 'Struts Users Mailing List' <[EMAIL PROTECTED]>
> > Subject: RE: Question about  struts-example struts-config.xml
> >
> > Craig wrote:
> > > Again, that's a carryover from the 1.0 (pre-dynabeans) approach.
> > > We should definitely clean this up to avoid confusion.
> >
> > I hate to complain, but the example really is confusing.
> 
> Don't feel bad!!!  None of the developers who have been around forever can
> see things from a newcomer's viewpoint as well as we'd like -- getting
> called on stuff like this is the best way to get it improved.
> 
> >  It also has a
> > bunch of code that makes you think you need to instantiate ActionForms
> > yourself:
> >
> >       if (form == null) {
> >         form = new SubscriptionForm();
> >             if ("request".equals(mapping.getScope())) {
> >                 request.setAttribute(mapping.getAttribute(), form);
> >             } else {
> >                 session.setAttribute(mapping.getAttribute(), form);
> >             }
> >     }
> >     SubscriptionForm subform = (SubscriptionForm) form;
> >
> > when I've been reliably informed (here!) that execute() will never, ever
> be
> > called with a null ActionForm parameter.
> >
> 
> Actually, there *is* a case when form will be passed as a null -- if
> someone were to modify the struts-config.xml entry for this action, and
> accidentally (or on purpose) remove the "name" or "attribute" attribute.
> Then, the controller servlet would assume that no form bean needs to be
> created, so it won't do so.

And if this happened, what would mapping.getAttribute() return? Assuming it
would be null, I'd expect the setAttribute call to blow up.

> So, this particular code could be called paranoid, but I'd rather protect
> myself against my own mistakes (or mistakes by others on the team) and
> avoid the possibility of a NullPointerException due to misconfiguration.
> 
> Note that this kind of a problem could not be detected at compile time, or
> even by static examination of just the Java code, and is also unlikely to
> be the sort of thing that unit tests would try to catch (how many people
> write unit tests with purposely broken struts-config files to see what
> breaks?).
> 
> If this were a real production application, would you rather find out
> about it when a user reports the ugly stack trace that would result, or do
> you want to spend a little time preventing some types of problems from
> occurring in the first place?
> 
> > I realize that code may just be there to make triple sure that the
> example
> > will not fail to run, but it could at least have a comment to explain
> that.
> >
> 
> We can add comments if you want, but at some point it also becomes an
> issue of personal programming style as well.  Over the years, I've shot
> myself in the foot enough times that it's embarrassing to think about.
> Because of that, I've developed some personal coding habits to try to
> minimize the possibility.  And, if you read TOMCAT-USER, you'll find that
> unexpected NPEs is a *very* common problem for newcomers to O-O languages.
> 
> > I know, I know... submit a patch. :)
> 
> Yep :-).
> 
> On a Unix platform (or Windows with CYGWIN), "diff -u" is the best way to
> prepare a patch.
> 
> >  I'm getting closer to figuring out how
> > to do that, but I'm not quite confident enough yet to mess around with
> what
> > is held up as "The Struts Example" app. ;)
> 
> But messing around with it can be a really useful way to learn :-).
> 
> And don't worry about breaking it for everyone else -- part of a
> committer's responsibility is to ensure that any accepted patches are
> doing the right thing.
> 
> >
> > --
> > Wendy Smoak
> > Applications Systems Analyst, Sr.
> > Arizona State University PA Information Resources Management
> >
> 
> Craig
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


-- 
Kris Schneider <mailto:[EMAIL PROTECTED]>
D.O.Tech       <http://www.dotech.com/>

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

Reply via email to