incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Janne Jalkanen <>
Subject Re: error handling Was: author ids
Date Mon, 25 Aug 2008 05:02:32 GMT

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...


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

View raw message