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: Kato API javadoc - error handling
Date Wed, 15 Apr 2009 22:52:00 GMT
With the aim of getting to a conclusion, shall we consider the use  
cases in this discussion?

For example, with a batch job, the visitor pattern (or something like  
it) might make perfect sense.
However, if we consider the Runtime Explorer, where we have an  
interactive list of objects, the visitor pattern would not make sense.

Also, does the current API provide all of the necessary information to  
satisfy these use cases?

Can I open the discussion to the following items not in the API (some  
may be already there but implicit, others irretrievable)?:

	Generics
	Inner classes
	Thread Groups
	Annotations
	Enums
	Shared classes
	JavaStackFrame/ImageStackFrame interleaving
	local variable information
	traversal over JavaObjects that are Collections, etc.
	
Are these items absences a hindrance to the use cases?
	

Regards,
	Stuart


For instance,

On 15 Apr 2009, at 20:21, Nicholas Sterling wrote:

> I'm finding this a very useful exercise.
>
> May I suggest a couple of minor tweaks:
>
>   ObjectVisitor objVisitor = new OurObjectVisitor() {
>       boolean visitField( JavaClass clazz, JavaField field, Object
>   value ) {
>           System.out.println(
>                         obj.getID()
>               + ": "  + clazz.getName()
>               + "."   + field.getSignature()
>               + " "   + field.getName()
>               + " = " + value
>           );
>           return true;
>       }
>   };
>   HeapVisitor visitor = new OurHeapVisitor() {
>       boolean visitObject( JavaObject obj )  {
>           obj.visit(objVisitor);
>           return true;
>       }
>   };
>
> That is, a single ObjectVisitor, created beforehand, can be used  
> with each object.  Also, you probably want the object visitor to  
> extend a customized OurObjectVisitor that handles exceptions.
>
> Presumably we would want the visitors to return true, to keep  
> going.  Alternatively we could supply a stopVisiting() method which  
> the visitor could call, and not return the boolean.
>
> Nicholas
>
>
> Stuart Monteith wrote:
>> I think 1. would be rejected on the basis that errors are common.
>> However, 3. would be accepted because errors are common i.e. most  
>> of the time they are logged and ignored.
>>
>> One thing I like about the Visitor pattern is that it is never left  
>> to the caller of the API to decide under what circumstances it  
>> should stop retreiving objects, the expectation is entirely on the  
>> API implementer to be able to complete. It's not the case that the  
>> API implementer might mistakenly place the responsibility for  
>> halting onto the API caller.
>>
>> The next level to examine the Visitor pattern would be to look at  
>> JavaClass and JavaField. The example I posted was of printing out  
>> all of the fields of all of the objects on the heap. The gnarly  
>> thing about this is you have to go through getting the Object, then  
>> the class, then the field, then applying them to the object.
>>
>> Would this be sensible?:
>>
>> interface ObjectVisitor {
>>   public void visitField(JavaClass clazz, JavaField field, Object  
>> value);
>> }
>>
>>      HeapVisitor visitor = new _OurHeapVisitor_() {
>>          boolean visitObject( JavaObject obj )   
>> {                        ObjectVisitor objVisitor = new  
>> ObjectVisitor() {
>>                  public void visitField(JavaClass clazz, JavaField  
>> field, Object value) {
>>                     System.out.println(obj.getID()+":  
>> "+clazz.getName()+"."+field.getSignature()+" "+field.getName()+" =  
>> "+value);
>>                  }
>>              };
>>              obj.visit(objVisitor);
>>          }
>>      };
>>
>>
>>
>> Nicholas Sterling wrote:
>>>>>>>>


Mime
View raw message