incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart Monteith <stuk...@stoo.me.uk>
Subject Re: API changes
Date Wed, 13 May 2009 13:07:28 GMT
Comments below...

Adam Pilkington wrote:
> 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
>   
The assumption here is that CorruptData object are checked deeply for 
whether or not they are entirely correct. Normally, CorruptData on an 
Iterator should be returned if there was a problem retrieving the 
object, not that all of its information is correct. I think that 
practically, object that are not CorruptData objects might still be able 
to throw CorruptDataExceptions.
For example, you might be able to retrieve a JavaClass successfully (no 
CorruptData), but getName() throws a CorruptDataException as the pointer 
to the name is corrupt.
The Iterator, or rather List, wouldn't check the name before returning it.
> 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();
>   
My assumption was that the CorruptData implementations were only 
returned by Lists. When they are being returned by methods directly, you 
will then need to check the type of everything returned by the API that 
is not a primitive or a type outwith the API. In which case, you will 
have to catch CorruptDataExceptions where there is a String or primitive 
returned. That might not be true if there are sensible defaults.
>      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
>   
Somehow, it has to be reported. e.getCorruptData() would return the 
presumably the same CorruptData as you'd two examples previously.
>   }
> }
>
>
> 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