incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Pilkington <pilkington.a...@googlemail.com>
Subject Re: API changes
Date Wed, 13 May 2009 12:19:22 GMT
Implementing a CorruptedData interface looks like a sensible way of
allowing the API to present strongly typed interfaces to the outside
world. However I would add that I prefer the approach of coding
runtime exceptions into the dummy object which is returned when the
data is corrupted. I don't see this as catching out callers as our
documentation should state something along the lines of "when
retrieving objects through a list (or other collection) interface, you
will need to perform a check to see if it implements the
CorruptedData" interface. I would see the runtime exception as an
approach to ensure that data is not accessed inadvertently from a
corrupt object (either through bad coding or the return of default
values), and is better than having every method declare that it throws
CorruptDataException. This has a knock on effect in that I can pass
objects that I know are not corrupt to other functions without having
that function either declare that it throws CorruptDataException or
handle it internally when that is never going to be the case.

I've also had a play around with the example For loop that Stuart
posted to see how things might work in either case.


JavaHeap heap = runtime.getHeap();

List<JavaObject> objects = heap.getObjects();

for (JavaObject obj : objects) {
  if (obj instanceof CorruptData) {
     System.err.println("Corrupt object: @ "+
((CorruptData)obj).getAddress()+":\""+obj+"\"");
  } else {
     JavaClass clazz = obj.getJavaClass();
     if (clazz instanceof CorruptData) {
       System.err.println("Corrupt object: @ "+
((CorruptData)clazz).getAddress()+":\""+obj+"\"");
       System.out.println("Instance: "+obj.getID()+" has a corrupt Java class");
     } else {

       System.out.println("Instance: "+obj.getID()+" instanceof
"+obj.getJavaClass().getName());
     }
  }
}


for (JavaObject obj : objects) {

  try{
    System.out.println("Instance: "+obj.getID()+" instanceof
"+obj.getJavaClass().getName());
  }catch (CorruptDataRuntimeException e){
    e.printStackTrace();            //can explicity catch the runtime
exception but this still has a problem, see next example
  }
}



for (JavaObject obj : objects) {

  try{
    System.out.println("Instance: "+obj.getID()+" instanceof
"+obj.getJavaClass().getName());
  }catch (CorruptDataException e){
    e.printStackTrace();            //OK, but we have to look at the
stack trace to see which objec was corrupt
  }
}


for (JavaObject obj : objects) {
  try{
    JavaClass clazz = obj.getJavaClass();

  }catch (CorruptDataException e){
    e.printStackTrace();
    continue;                //cannot proceed with processing if I
can't get a JavaClass object

  }
  try{
    System.out.println("Instance: "+obj.getID()+" instanceof
"+obj.getJavaClass().getName());
  } catch (CorruptDataException e) {
    System.out.println("Instance: "+obj.getID()+" has a corrupt Java class");
    e.printStackTrace();
  }
}


2009/5/13 Stuart Monteith <stukato@stoo.me.uk>
>
> Hello All,
>   I'd like to start a discussion on changes to the API we should make before the Early
Draft Review of the API.
>
> One change to make would be to replace the Iterators with Lists. Steve has expressed
a strong desire to do so as it will enable more useful ways to access the API.
> Connected with this is the exception handling. Just now we return CorruptData objects,
but these don't work when the Lists are strongly typed using generics.
> Carmine has suggested always returning objects of the appropriate type, but instead have
dummy objects of the appropriate type also implement the CorruptData interface.
>
> As I see it it would look like so:
>
> interface JavaHeap {
>   List<JavaObject> getObjects();
> }
>
> Then we'd ordinarily return at least an object like so:
>
> class JavaObjectImpl implements JavaObject {
> }
>
> and in error cases:
>
> class JavaObjectCorruptImpl implements JavaObject, CorruptData {
>   public ImagePointer getAddress() {
>      return badAddress;
>   }
>
>   public String toString() {
>      return badMessage;
>   }
>
>   public boolean isArray() {
>      throw new RuntimeException("This object is corrupt.");
>   }
> }
>
> so we would do something like the following:
>
> JavaHeap heap = runtime.getHeap();
>
> List<JavaObject> objects = heap.getObjects();
>
> for (JavaObject obj : objects) {
>   if (obj instanceof CorruptData) {
>      System.err.println("Corrupt object: @ "+ ((CorruptData)obj).getAddress()+":\""+obj+"\"");
>      continue;
>   }
>
>   try{
>       System.out.println("Instance: "+obj.getID()+" instanceof "+obj.getJavaClass().getName());
>   }catch (CorruptDataException e){
>      e.printStackTrace();
>   }
> }
>
>
> Does this look sensible? More importantly, is this an improvement?
>
> I don't like the idea of using a runtime exception within the corrupt object, I'd much
prefer to return a CorruptDataException, with it perhaps returning itself.
> Of course, this means adding CorruptDataException to every method, but at least that
way we're not catching out our callers.
> An even more friendly means of dealing with this problem is to use Steve's idea of having
sensible defaults. Having said that, I don't like the idea of defaults messing up the statistics
that may be being collected.
>
> Looking forward to your thoughts and comments,
>   Stuart
>



--
Regards

Adam Pilkington

Mime
View raw message