incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Julin <>
Subject Re: Kato API javadoc - error handling
Date Mon, 13 Apr 2009 00:12:43 GMT

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?

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