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
Date Wed, 08 Apr 2009 01:17:07 GMT

I would like put in a good word in favor of checked exceptions.

One key thing to keep mind is that minor errors are actually quite common
and often unavoidable when analyzing a dump. For example:

* Some data items may appear corrupted or inconsistent because they were
caught "in flight" at the instant when the dump was generated

* Some data items may not be present, depending on the circumstances, the
method used to obtain the dump and the implementation of a particular
reader. For example, in some cases dumps from Linux do not contain full
information about all the native threads, because the Linux kernel itself
does not put it in the dump.

>From our experiences with the DumpAnalyzer tool over the past couple of
years, it's not unusual to have dozens or even hundreds of small errors
like that while walking through a typical dump, and they do not generally
degrade the overall usefulness of the analysis. In the DTFJ API, these
result in a DataUnavailable or CorrupDataException. The DumpAnalyzer tool
catches the exception right at the point where it happens, prints a simple
"[<unavailable>]" or "[<corrupted>]" tag at the appropriate point in the
output, and moves on with the rest of the dump analysis.

Having these reported through checked exceptions obviously makes it much
easier to write a tool that carefully checks for all such potential errors
and handles them in as narrow a scope as possible. The price is indeed that
we have to have try/catch blocks all over the place. It's annoying, but it
does not really make the code any more complicated than if we had to have
an explicit test for an invalid value everywhere. And, if our code
compiles, we can be sure that we did not forget to put a check for an error
condition somewhere. Unchecked exceptions, of course, do not give us that

I recognize that, conversely, this makes life somewhat more complicated for
the sustaining engineer who wants to write a quick simple program for some
special analysis, and who does not want to spend a lot of time writing lots
of error handling code. But all these exceptions from the Kato API are
subclasses of DTFJException. So, he/she can simply declare every method in
his/her program with "throws DTFJException", and have a single global
try/catch block at the top level of the program to catch any DTFJException
and abort the program gracefully. Is that really too onerous?

-- Daniel --

Nicholas.Sterling@Sun.COM wrote on 2009-04-06 06:11:35 PM:
> I personally prefer unchecked exceptions, Steve.  Let me see if I can
> articulate why.
> If a sustaining engineer is working on a problem with a customer, s/he
> may write a little program using this API to rummage around in each of
> the stream of core files they will get as they try various experiments.
> The sustaining engineer thinks s/he knows the situation: that an image
> contains a single process, that it is a Java program, that a particular
> thread exists, that a particular class is being used, etc.  Sure, they
> could codify their assumptions by writing explicit checks, but it would
> be more straightforward to just write the code saying "give me thread
> X."  They will be sorely tempted to do that; it's easier, and such code
> will be easier to grok when passed around.
> Unfortunately, if they do that and the API returns special values for
> exceptional conditions, then if one of their assumptions *is* violated
> their analyzer is going to blow up in some strange way, perhaps
> downstream a bit from the violated assumption, and now they're debugging
> their analyzer instead of the customer's problem.
> If, however, unchecked exceptions are used, then the sustaining engineer
> could just assume everything they expect to be there actually is there,
> and the API will tell them if they are wrong -- clearly, and precisely
> at the location of the violated assumption.  Aha!  There is no thread
> X.  99% of the time there assumptions will be correct, so let them just
> assume what they want to.  And the 1% of the time they are wrong, it
> isn't a brain-teaser in its own right.
> It is because I am hoping that the API will prove useful for such ad-hoc
> analysis that I prefer not to encumber the API by requiring explicit
> tests or exception-handling.
> Of course, people writing serious generic diagnostic tools can't assume
> anything; their tools will have to deal with all possibilities,
> everything the API could return.  Regardless of whether we use special
> values or exceptions, they'll have to code for the uncommon case.
> Honestly, I think *checked* exceptions would be best for them, because
> they couldn't forget to catch an exception.  But checked exceptions
> place constraints on the API's evolution, and again, they make life
> harder for the sustaining engineer who thinks s/he knows the situation
> (by requiring explicit handling for each exception).
> Just my 2 cents.
> Nicholas
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message