OK, now you are making sense.
I think that might actually be a pretty cool idea, if that works.
And should that fail, we can always catch RedirectExceptions in our
ActionBean superclass and do the right thing there...
/Janne
On 25 Aug 2008, at 06:30, Andrew Jaquith wrote:
I take that last e-mail back. This is what happens when you think
about an issue but don't think through the answer. :)
And of course, in this case, I had a particular issue in mind...
(readers: skip, if not interested in 3.0 talk...)
...chiefly related to (guess!) Stripes. There's a special kind of
interface called a "Resolution" that Stripes uses to mediate
unexpected redirects and forwards. It seemed to me that our
RedirectException is a bit problematic in a Stripes world, in the
sense that it doesn't much like other classes to do redirects... it
would rather manage these itself.
So, my rather casual, not-thought-through thought was that
RedirectException might needs to become a "Resolution" that can be
handled properly by the StripesFilter and/or useActionBean tag. In
particular, I was thinking that perhaps RedirectException might
need to subclass RedirectResolution. Which led me to send of a
short e-mail that made no sense... because Exception is a concrete
class and not an interface.
But, on further inspection we do NOT need to do change any of the
subclassing. What we can do, instead, is modify RedirectException
to implement the Resolution interface, and if it needs to mimic
RedirectResolution, do it through composition (i.e., a delegate)
rather than inheritance.
Ok. These are not the droids you were looking for...
On Aug 24, 2008, at 1:55 PM, Janne Jalkanen wrote:
Hm? Then you can't throw a WikiException, since it does not
extend Exception... Perhaps you mean an abstract class?
/Janne
On 24 Aug 2008, at 20:45, Andrew Jaquith wrote:
One more thing: I think we should also turn WikiException into an
interface...
On Aug 24, 2008, at 1:42 PM, Andrew Jaquith wrote:
The short answer: +1
The longer answer:
Yeah, I do think we should throw more checked Exceptions... the
NPEs (unchecked) are always a pain in the butt to debug.
IllegalStateExceptions are a little easier to deal with, because
they generally supply a good stack trace and error message.
That said, I don't think we should be overly aggressive about
wrapping caught Exceptions in WikiException, because it tends to
dilute to root cause, which might be more usefully dealt with
upstream. For example, any of the Exceptions generated by core
classes (and propagated upwards to the presentation tier) should
be as specific as practical so we can redirect users gracefully.
Not to beat the Stripes drum too much, but it has a neat
ExceptionHandler class that is, in essence, a super-duper
"exception catcher" that can return different Resolutions (for
example) depending on the class of exception. Right now the
subclass I've created (WikiExceptionHandler) doesn't do anything
but forward/redirect to Error.jsp. But it could do a lot more.
Being as specific as possible would help.
So, I think we should:
- Discourage returning nulls in favor of checked Exceptions
(where practical)
- Return specific Exceptions rather than the generic
WikiException (where practical)
Andrew
On Aug 24, 2008, at 12:44 PM, Janne Jalkanen wrote:
Had a few minutes to myself this morning, so I committed the
changes to UserProfile/UserDatabase classes. Uids are now
Strings.
Looks good :-)
This reminds me of another thing:
JCR prefers throwing a wild array of Exceptions to describe any
anomalic situation. JSPWiki has so far been pretty light on
these, with most accessor methods like WikiPage.getLastModified
() returning a null in case of a problem.
What is the general feeling on this, should 3.0 propagate
exceptions upwards (possibly wrapping them inside
WikiExceptions), or catch them early? Throwing the exceptions
makes the coder's life a bit more tenous because they have to
be caught and examined, but on the other hand, they do make the
code more robust (and protect against hazy NullPointerExceptions).
/Janne
