Re: On Faults

+1.

On reflection, I don't think we can (or should) predict when a fault
might occur. This is somewhat analoguous to exceptions in programming 
languages versus checking return codes.

Jean-Jacques.

Amelia A. Lewis wrote:
> I'd like to propose, probably for later consideration, that we drop
> the explicit characterization of faults in exchange patterns.
> 
> I believe that the inclusion of faults in the patterns simply
> confuses the issue.  It also potentially multiplies the number of
> patterns, as each different fault-handling paradigm creates a
> separate 'dialect' of each pattern.
> 
> There are two fairly straightforward rules that could be adopted in
> place of the current explicit definition.  Moreover, it might be
> possible, using the properties mechanism, to specify per-protocol
> binding or per-service, which fault-handling rule should be used.
> These two rules are:
> 
> 1. Any message may trigger a fault in response. 2. A fault may
> substitute for any message after the first in a pattern.
> 
> #2 is appropriate, for instance, for HTTP.  #1 is more likely to be
> encountered in asynchronous sorts of protocols.
> 
> I'd like to make this a proposal, but not as a high priority, as we
> are currently focusing on issues of "what is a MEP" and "MEPs versus
> IOPs" and "which belongs in portType/interface?".
> 
> Amy!

Received on Tuesday, 1 April 2003 03:03:00 UTC