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:26:08 GMT

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 

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.


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

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