incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicholas Sterling <Nicholas.Sterl...@Sun.COM>
Subject Re: Kato API javadoc - error handling
Date Mon, 13 Apr 2009 03:34:04 GMT
And a Handler (whatever it should really be called) would have access to 
the previous Handler on the stack, so it could do

    void handleJavaObjectUnavailable(...) {
        // do some stuff, then defer to the guy beneath us on the stack:
        prevHandler().handleJavaObjectUnavailable(...);
    } 

Nicholas


Nicholas Sterling wrote:
>
>
> Daniel Julin wrote:
>> I like that approach a lot, because it may also address the other 
>> concern
>> that a proposed "default reasonable behavior" may not be appropriate for
>> all usage scenarios. We could probably come-up with a variety of 
>> handlers
>> for various common behaviors, like printing a simple error message,
>> completely ignoring the error, and lots of other creative responses.
>>
>> Incidentally, nothing in this discussion is particularly specific to the
>> Kato API, is it? Are we saying that, in general, we don't like 
>> exceptions
>> as the standard mechanism to report errors in Java, and that we're
>> inventing new patterns?  If so, have any useful patterns been 
>> proposed and
>> documented previously in the literature?
>>   
> I just looked around a little, and am only seeing suggestions for how 
> the *client* can abstract out the exception-handling logic using the 
> Template design pattern.  So far I haven't seen any advice for API 
> designers.
>
> By the way, it occurred to me that the setter can have a generic name 
> because overloading will allow us to have a method for each condition:
>
>    factory.setHandler( new DataUnavailableHandler( ... ) {
>        ...
>    } );
>
> Also, it might make sense to push the handler on a stack rather 
> replace what is there.  That will allow independent modules to modify 
> just that behavior they need to and then remove those modifications 
> when they are no longer needed.  It also means that we can have just 
> one Handler() class for all the handlers, e.g.
>
>    // Temporarily override the handling of DataUnavailable errors.
>    factory.pushHandler( new Handler( ... ) {
>        void handleJavaObjectUnavailable(...) {
>            // handling specific for JavaObjects
>        }
>        void handleDataUnavailable(...) {
>            // handling for all other DataUnavailable conditions
>        }
>        // All handler methods not overridden will simply call the same 
> method
>        // for the object beneath us on the stack.  If we get to the 
> bottom, the
>        // handler there will throw an exception.
>    } );
>    // Do some work that might cause an exception.  This might include 
> calling
>    // an independently written module that also wants to temporarily 
> override
>    // some handler, but they will pop that before returning to us.
>    factory.popHandler();
>
> Nicholas
>
>>
>> -- Daniel --,
>>
>>
>> Nicholas.Sterling@Sun.COM wrote on 2009-04-11 01:48:53 AM:
>>  
>>> Daniel Julin wrote:
>>>    
>>>> I guess a two mode approach would make everyone happy. But would it
>>>>       
>> make
>>  
>>>> the API too complicated?
>>>>
>>>>
>>>>       
>>> I have some sympathy for what Steve is talking about -- maybe my
>>> short-term memory is small, but when lots of single lines of code
>>> inflate to 6 lines (and two indentation levels), it is definitely 
>>> harder
>>> for me to read.  However, I wouldn't want to give up the certain and
>>> immediate catching of errors offered by exceptions.
>>>
>>> Would a mechanism like this work for the two-mode approach?
>>>
>>>     factory.setDataUnavailableHandler( new DataUnavailableHandler( 
>>> ... )
>>>     
>> {
>>  
>>>         ...
>>>     } );
>>>
>>> All objects created by the factory would call that object's
>>> dataUnavailable() method when appropriate, passing it enough info about
>>> what was going on to allow the method to make interesting decisions
>>> about what to do.  The default handler would always throw a
>>> DataUnavailableException.
>>>
>>> It's hard for me to tell whether something like that would really
>>> suffice in actual use.  Perhaps it would have to be finer-grained, with
>>> methods for javaObjectUnavailable(), imageSectionUnavailable(), etc.
>>> Perhaps the defaults for those would call the more generic
>>> dataUnavailable() so that you could intervene for all cases and/or for
>>> individual cases as desired.
>>>
>>> Nicholas
>>>
>>>     
>>
>>   
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message