webwork-devel

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

[<Jim...@do...>]

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

Now, if there is an error instantiating this object in prepare(), such as=20
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=20
bail, which means I have to wrap all of my setters with a "if (object !=3D =

null)" methods.

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

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

a RuntimeException. I didn't see any design issues, especially since you=20
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?) ;-)

-jim





Rickard <ri...@mi...>
01/22/2002 06:40 PM

=20
        To:     Jim...@do...
        cc:     web...@li...
        Subject:        Re: [Webwork-devel] ResultException in prepare()


Jim...@do... wrote:

> It would be handy to be able to throw a ResultException from prepare(),=20
> especially in our Update actions. Any hope of extending the try block in =


> ServletDispatcher around the ActionFactory.getAction(actionName) method?


Well, no, not really. ResultException is just a fancier way of selecting=20
the return value from execute(), and prepare() is not done as a part of=20
that process, but rather as a part of the instantiation.

Why do you want it?


> Also, I would suggest that ResultException extend RuntimeException.=20

Well.. it doesn't make much difference for execute() since it throws=20
Exception.

/Rickard

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

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!