Mailing-List: contact dev-help@tuscany.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@tuscany.apache.org
Received-SPF: pass (nike.apache.org: domain of
 mike.edwards.inglenook@gmail.com designates 209.85.218.214 as permitted
 sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=UquIvpXURUZJ3Lp79gEr9TGKkhseE4+RwKDUmoyACfft7qAxeKwZR1l02WYcw0agma
         wkrJaoTxLCvorzkLN0zfRlMRuKn7L/j4AtuvXM1qtIAx3G+Ax/bLvt4rhzc5zd2mlEf0
         IHIXl2bLIppYd9S6yelkhAiWgqVZ9ERhXzC/Q=
Message-ID: <4A76DA7A.4080906@gmail.com>
Date: Mon, 03 Aug 2009 13:39:22 +0100
From: Mike Edwards <mike.edwards.inglenook@gmail.com>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: dev@tuscany.apache.org
Subject: Re: [2.x] error handling improvements
References: <c0c051b50907151359ofb105ecgc25f286701d681ec@mail.gmail.com>
	 <c0c051b50907180106w6c3ca028nd09c08cb474f3892@mail.gmail.com>
	 <4A631554.2030000@apache.org>
	 <c0c051b50907221331v62a67584g762f6c0dde6f3b51@mail.gmail.com>
	 <4A67B4B7.3060600@apache.org>
 <4A6816A9.20103@gmail.com>	 <4A6B6BEE.7010507@apache.org>
 <4A6D5222.4020509@apache.org>
	 <c0c051b50907270116t5ead4166na6c3cf4249bc9fe6@mail.gmail.com>
	 <4A6D6BD8.9000208@apache.org>
 <334325fb0907290123m3f17c2efs759ee01005195a4e@mail.gmail.com>
 <4A70D482.60700@apache.org>
In-Reply-To: <4A70D482.60700@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Folks,

Comments inline.

Simon Nash wrote:
> Mike Edwards wrote:
>> Folks
>>
>> 2009/7/27 Simon Nash <nash@apache.org <mailto:nash@apache.org>>
>>
>>     Simon Laws wrote:
>>
>>         I think there are least two issues here that are becoming 
>> confused
>>
>>         1 - how to get context information for an error or warning. It 
>> think
>>         three suggestions have come out on this thread
>>         1-1 - push/pop it into the monitor
>>         1-2 - change method signatures to pass it down
>>         1-3 - catch thrown exceptions and add it after the fact
>>
>>         2 - should we stop processing after an error
>>         2-1 - yes
>>         2-2 - no, and make all subsequent processing immune to NPE etc.
>>         2-3 - maybe - depending an anaylsis of what code follows
>>         2-4 - maybe - depending an anaylsis of what code follows and on
>>         whether context is available for the first error
>>
>>         I don't mind which answer to question 1 we choose. I started
>>         with 1-1
>>         but am happy to accept but 1-2 and 1-3 can also be made to 
>> work for
>>         us. I would though argue for consistency. I.e. we try and 
>> follow a
>>         single pattern so that, as we develop new function and maintain
>>         existing function, it's clear what we are supposed to do.
>>
>>     If we are going for consistency then I think 1-1 is not an option
>>     because of runtime situations that don't fit this pattern.  I think
>>     we are likely to need a mixture of 1-2 and 1-3 depending on the code
>>     execution path.
>>
>>
>> Would you care the explain in detail why 1-1 is not an option?  I 
>> happen to think it is the best option by far.  The Monitor is all 
>> about handling error reporting in a way that is friendly to SCA, so 
>> adding the context there seems simple and natural to me.
>>
> I think 1-1 could be made to work for the single-threaded stack-based
> part of the runtime (read/resolve/build/activate/deactivate/start/stop).
> However:
> . It would need a lot of added code to push and pop the correct
>   context info at the right times.
> . This approach is not robust because if the pushes and pops get
>   out of sync, the compiler could not detect this and the result
>   would be incorrect context information in error messages.
> 

It will be a lot of work to add context parameters to all the relevant methods and ensure that those 
parameters are set up correctly by the calling code.  The calling code will have to handle push & 
pop in precisely the same way anyway - the calling code will inherit some context from its callers 
and must add its own piece before calling down. It must also pop off any of its context before 
returning.

> Adding new information to the signatures can be enforced by the
> compiler, so we would have more assurance that the correct context
> information will always be present.  I agree that this would require
> quite a lot of code changes, but the compiler would tell us if we
> missed anything, and I'm not sure whether it would be a lot more
> work than adding all the necessary pushes and pops.

I don't think that this can be the case - you may have a different model than I do, but the context 
information is a stack of information of varying form.  I don't think that signatures are going to 
be of much use in handling such a data structure - certainly I doubt that any enforcement is going 
to help get the context right.

> 
> Also, this stack-based single-threaded approach doesn't work for
> runtime messages produced by multiple concurrently executing threads.
> These threads already contain a thread-local "message" object and
> I think this would be a suitable place to maintain runtime context
> information.
> 

This is true, but in reality at runtime, the situation is actually simpler.  At runtime you have 
wires/chains associated with Endpoints and EndpointReferences, which in turn are associated with 
RuntimeComponents - and the RuntimeComponents have unique structural URIs that then link back to the 
original model.  Tracing out these relationships is what is needed at runtime.  What we need to 
write is tracing code that reconstructs the context by following all these links.

>   Simon
> 
>> 1-2 seems like an insane amount of work for little added value.
>>
>> 1-3 is the option I suggest for "foreign" code that we use, where we 
>> are not in control of the situation (eg WSDL processors), but that we 
>> should catch the exceptions as quickly as possible in our own code, 
>> where we can apply the context.  Without the context, the exceptions 
>> are pretty well useless.
>>  
>>
>>
>>
>>         My preference for 2 is 2-1. If the consensus is really that we 
>> must
>>         continue processing after an error then again I would argue for
>>         consistency and clear rules for the situations under which this
>>         processing is carried out. My second preference would be for 2-3.
>>
>>     For runtime errors we have no choice but to do 2-1.  For build-time
>>     errors I have a strong preference for 2-3 because I think it will be
>>     a big step backwards in usability if only one error in the static
>>     artifacts can be detected at a time.
>>
>>     2-2 would be far too much work.  2-4 doesn't have sense to me as we
>>     should always be producing context when we have addressed issue 1.
>>
>>
>>
>> 2-3 makes sense to me in the following way.  We will quickly get to 
>> understand which problems cause unwelcome cascades of errors - when we 
>> find these we simply raise the severity of the problem so that further 
>> processing is stopped.  The OASIS tests already cause an interesting 
>> pile of errors (deliberately) and these can be used as an initial 
>> contriibution to working out which problems must be raised to a 
>> severity that stops further processing.
>>  
>>
>>
>>      Simon
>>
>>         Regards
>>
>>         Simon
>>
>>
>>
>>
>> Yours,  Mike.
> 
>