I see your point that there has to be some design to handle? that contingency (exceptions coming from the constructor) but with so many opportunities for us to do things via interceptors I would let the framework have a total monopoly on the constructors.
Essentially we (application developers) should be into how the action behaves rather than how it comes into being. But I do see your point that for completeness there has to be some definite behavior that takes place if the exception is thrown. Chris -----Original Message----- From: Jan T. Kim <j....@uea.ac.uk> To: Struts Users Mailing List <user@struts.apache.org> Sent: Thu, Jun 25, 2009 9:05 am Subject: Re: Exceptions thrown by constructor different from those thown by execute() ? Dear Chris, On Thu, Jun 25, 2009 at 08:23:30AM -0400, musom...@aol.com wrote: > > I am with the devs on this one -- typically the constructor of an object whose life cycle is managed by > the framework is off limits -- you wouldn't write code to throw exceptions from a servlet or > EJB etc. I agree that from an EJB provider's angle its quite possible to argue that session bean's constructors shouldn't throw exceptions. From an application assembler's perspective, though, I'd expect that a global exception mapping would handle all exceptions of the specified class, regardless of whether they are thrown by constructors or other methods (and regardless of whether the exception is considered legitimate or reasonable). Best regards, Jan > > > > -----Original Message----- > From: Wes Wannemacher <w...@wantii.com> > To: Struts Users Mailing List <user@struts.apache.org> > Sent: Tue, Jun 23, 2009 9:03 am > Subject: Re: Exceptions thrown by constructor different from those thown by execute() ? > > > > > > > > > > > On Tue, Jun 23, 2009 at 8:50 AM, Jim Kiley<jhki...@summa-tech.com> wrote: > [...] > > From a philosophical perspective, though -- no clue, I don't have a lot of > > insight into why the devs make all the decisions they make. > > > [...] > > The decisions I make are usually heavily weighted by how impressed > girls will be :) > > I would go against adding security via exceptions thrown by a > constructor. In the default ObjectFactory for xwork, the flow for > creating instances of classes is pretty easy to follow. The exception > handling is deferred to callers (as evidenced by the various "throws > Exception" qualifiers on the methods). The main reason I would be > against it is that you aren't the one calling "new" on the classes. I > can appreciate what you are trying to do, so file a JIRA and when we > have time to investigate, we could probably implement it, but to solve > your problem, the best bet is an interceptor. > > -Wes > > -- > Wes Wannemacher > Author - Struts 2 In Pr actice > Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more > http://www.manning.com/wannemacher > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > > > > > > -- +- Jan T. Kim -------------------------------------------------------+ | email: j....@uea.ac.uk | | WWW: http://www.cmp.uea.ac.uk/people/jtk | *-----=< hierarchical systems are for files, not for humans >=-----* --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
