incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Janne Jalkanen <Janne.Jalka...@ecyrd.com>
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...

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


Mime
View raw message