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: Remaining Specification topics
Date Thu, 10 Sep 2009 21:07:30 GMT
On Thu, Sep 10, 2009 at 3:21 PM, Adam Pilkington <
pilkington.adam@googlemail.com> wrote:

> Hi, I think that there is an additional topic which needs to be added
> to the list of outstanding items. Although it is not strictly a design
> activity, more a strategy, design decisions will need to be made in
> order to adhere to it (if we accept that it should be addressed). What
> I propose is that implementations of this JSR are required to adopt a
> 'best can do' approach to returning data to the user. What I mean by
> this is that it is not acceptable to be unable to provide information
> through the API in the event that a non fatal error occurs when the
> underlying data in the core file is being processed. Core files are
> often produced in less than ideal circumstances and data integrity
> problems should be expected and be treated as 'business as usual'. A
> simple example could be iterating over the stack frames and finding a
> corrupt one - an implementation would be expected to return the stack
> information up to the point of the corruption followed by an object
> which implements a CorruptData interface, rather than to just throw a
> CorruptDataException.
>
> One implication of adopting this 'best can do' approach is that when
> an error occurs you may be able to silently deal with it and complete
> the operation, however in terms of problem determination you may have
> lost information which could be important in debugging. This
> information may be important to the tool which is consuming the API,
> but of less importance to the user viewing the information through the
> tool. Take for example executing a JavaObject.arraycopy(). It may well
> be that as you are traversing the array you come across an invalid
> memory address for one of the elements in the array, so rather than
> fail the entire copy operation you insert a CorruptData object into
> the target array and carry on. The API consumer can detect that one of
> the array objects is corrupt, but you have potentially lost vital
> information. What I would suggest is that an internal error/message
> queue is created onto which more detailed, perhaps also more low
> level, information is placed and linked to the returned item via the
> objects ID (by ID I mean the value that is returned by calling getID()
> on the object). This would allow you to link the error information to
> the returned object. It would also allow the operation to complete and
> honour the 'best can do' approach. A similar approach is adopted by
> the Firefox browser in that it will always attempt to render what it
> can to the user, but if you open the error console in a separate
> window, you can see all the errors or warnings that were encountered
> and what action was taken.
>
> The final part of this is that the API would need to be expanded to
> allow this error information to be exposed to API consumers (but not
> necessarily the end users)
>
> Does this sound like something that is worth taking forwards ?
>
> I sort of think this is part of a discussion we had on this list for what I
coined "no nulls"  - ie you always get something back when you ask.
I had wondered how to deal with the two opposite requirements :
       one when you want to know about corrupt objects (perhaps because
that's what your looking for),
       the other when you don't want to know about corrupt /  incomplete
objects

You've explained what Firefox does and I can see your thinking.   I think
its a good idea.   Would this mean that the concept of the Corrupt exception
or corrupt data goes away?
Would we have an API where , as you put it,  its always best can do?  and
you always get an object - even if its synthetic?



> 2009/9/8 Steve Poole <spoole167@googlemail.com>:
> > hi all,
> >
> > Now we have a first specification draft I've been thinking about the
> > remaining design activities that need to be closed before we can call the
> > JSR complete.  Here's my list.  I'll send out a specific email for each
> one
> > to keep the threads separate.
> >
> >
> > 1 -  Round tripping entity identity.   Its desirable to be able to get a
> > handle to an entity within a dump and then come back later and ask for
> the
> > entity by handle.
> >
> > 2 - Standardising access to internals.   The Java runtime API is
> > inconsistent in offering support for accessing the internal data of an
> > entity.
> >
> > 3 - Optionality - how do we  define a mechanism that allows a dump to
> > explain what it contains.
> >
> >  4 - "Snapshot" support - We need to determine what the direction is for
> > supporting smaller, faster and content configurable dumps.
> >
> > Cheers
> >
> > Steve
> >
>
>
>
> --
> Regards
>
> Adam Pilkington
>

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