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
