incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Julin <...@us.ibm.com>
Subject Re: Kato API javadoc - error handling
Date Sat, 11 Apr 2009 02:06:48 GMT

Steve Poole <spoole167@googlemail.com> wrote on 2009-04-08 04:46:25 AM:
...
> I'm not happy with leaving things as they are, as currently the API is
not
> very programmer friendly.   I do understand the points made on this
subject
> so far but I still think that the  "no nulls" approach is the best
> approach.    Why?  here are my reasons
>
> 1 - Code robustness -  both API consumer and API provider have to deal
with
> missing or corrupt data - and this could happen anywhere at anytime.
> Programmers love to write  chained methods  like foo().getbar().getname()
> My real worry is that Joe RandomDeveloper will write his clever tool
using a
> favourite platform / dump  which then fails when run elsewhere because of
> unexpected missing data etc.

I think this issue of never returning nulls is distinct from the question
of how to properly report errors. Certainly we don't want to get nulls in
random places when there was some specific API error or problem, as this
may cause NullPointerExceptions that are indistinguishable from many other
kinds plain bugs that we may have in our code. In other words, non-buggy
code should never see NullPointerExceptions :-)

Having a dummy static or a well-defined and specific exceptions allows us
to carefully pinpoint what the problem is. As an added bonus, note that the
dummy value or the special exception can contain a "reason" string that
provides more detail about exactly what went wrong (many of the
DataUnavailable and CorruptDataExceptions thrown in the current
implementation do so already, and the DumpAnalyzer tool, for example,
prints these reason strings in the error log)

> 2 - Sensible default behaviour for missing or corrupt data -   Missing or
> corrupt data is an indicator that something is not right - what are you
> going to do with it?  Its either an "all bets are off" signal or you are
> just going to assume some default behavior.  We should do that for the
> programmer and make the API easier and friendlier to use.

Frankly, I'm not sure that we can define a reasonable default behavior that
is satisfactory for all possible use cases. I think we'd have to carefully
review a collection of real proposed used cases to be sure.

To use the DumpAnalyzer tool as an example, I can think of two main
behaviors that we use when encountering minor errors (there may be others
that just skip my mind at this time):

- sometime we print a detailed and very specific error indication, at a
very specific point in the output and in the right context. For example:

    Current Thread: [<unavailable>]

- sometime we set a flag to remember that one particular area of our
analysis is flawed, and use that knowledge to influence other parts of the
analysis. For example, while we're scanning all the JavaClassLoader and
JavaClasses to build a dictionary mapping class names to JavaClass
definitions. If we have an error while reading some of the JavaClass
instances but not all, or if we find multiple definitions of the same
class, we emit the dreaded message "Warning: class lookups may be
unreliable", but we continue building our classname dictionary, and use it
throughout the rest of the analysis. In practice, this particular example
happens a lot!



> 3 - Programmer friendlyness -   see above.   I absoletely hate the fact
that
> the current API design forces me to put try catch blocks around every
call.
> if I wanted to report the values on a object I have to do this sort of
> horror ...
>
> String field1=null;
> String field2=null;
>
> try {
>
>  field1=foo.getField1();
> }
> catch(DTFJException e} {
>    ;
> }
> try {
>
>  field2=foo.getField2();
> }
> catch(DTFJException e} {
>    ;
> }

I guess I don't get it. As a programmer, I'd like the compiler to tell me
about as many possible problems in my program at compile time, rather than
waiting until runtime tests to hope to catch all the things that I might
have forgotten to guard against. And I'm willing to pay a little price in
added ugliness and verbosity of my code, for that benefit.

And remember, if you don't want to handle errors at a fine granularity, you
don't have to put try/catch blocks everywhere. You can just put one single
global try/catch block around your entire program, and hope for the best...


>
> May be I'm arguing for a two mode approach  in which I can tell the API
if
> I want to receive exceptions or get default data.   I do know that I do
not
> want  perpertuate the above.

I guess a two mode approach would make everyone happy. But would it make
the API too complicated?



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