incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Poole <spoole...@googlemail.com>
Subject Re: Kato API javadoc - error handling
Date Tue, 14 Apr 2009 16:43:48 GMT
On Mon, Apr 13, 2009 at 4:34 AM, Nicholas Sterling <
Nicholas.Sterling@sun.com> wrote:

> 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
>
> This is cool -  The callback approach is sort of a half way house between a
DOM and SAX model.  It could allow us to have a default "no nulls" approch
for an implementation but still allows for users of the API to do something
different.

I think we should create some comparison code segments to see what it could
look like.

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