Re: [Webwork-devel] ResultException in prepare()

[Rickard <ri...@mi...>]

Jim...@do... wrote:

> I would like it in prepare because we often instantiate an object in 
> prepare. Then, the subsequent setXXX methods can have an object to go 
> against, as opposed to storing the setXXX values in intermediate dummy 
> strings and such.


Yup, that was the idea.


> Now, if there is an error instantiating this object in prepare(), such as 
> a finder exception, I would like to addError() and get the heck out with a 
> ResultException(INPUT). Without this, I have to wait until doExecute() to 
> bail, which means I have to wrap all of my setters with a "if (object != 
> null)" methods.


Your "setters"? These are called by WW, and not your own code. Adding an 
error is indeed a good way to trap it.


> It seems much cleaner to extend the try block to include the getAction() 
> call.


How would you propose then that action delegating work, i.e. where an 
action uses ActionFactory.getAction() to do delegation? How would code 
doing that look like?


> As to extending RuntimeException, I ran into a situation where I was 
> extending ResultException, and it was more convenient for me to have it as 
> a RuntimeException. 


Why? Can you give example code?

> I didn't see any design issues, especially since you 
> are expecting it to be only called in execute(). I can think of situations 
> when I would prefer it to be called in prepare(). (Full circle, no?) ;-)


See above, result selection should only be done in execute(), but it's 
ok to let errors from prepare() influence that selection. But the 
selection itself should not be done in prepare() I think, or we would 
have to revise the entire action lifecycle pretty heavily.

/Rickard

-- 
Rickard Öberg
Author of "Mastering RMI"
Chief Architect, TheServerSide.com
   The Middleware Company - We Build Experts!