[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 219 - proposal to vote
Alex, I don't think we should try and add smart semantics to the fundamental error condition that caused the fault. The fault could be caused by a bug in the language processor that was exposed by a specific (complex :) XPath expression that is involved. By requiring an override to throw the correlationViolation fault we could be creating a debug nightmare. I think we should let the fault that corresponds to the problem recognized be thrown in this case. I have learnt to put additional catch blocks, when I ran into the fault that was not necessarily declared. Saving couple of catch blocks is not worth it in this case. Perhaps we can add a caution that indicates multiple fault conditions are possible rather than convert into a different fault by a ruling in the spec. Regards, Prasad Alex Yiu wrote: > Hi, > > If we don't use correlationViolation fault here, there will be a > number of possible faults thrown - subLanguageExecutionFault, > selectionFailure, incompatibleAssign ... One thing I am trying to > avoid here is to ask users to catch all these kinds of faults. I can > forsee some of not-so-hardworking BPEL programmers will just use a > <catchAll> to handle all these faults instead of having just one > <catch> on correlationViolation. > > And, those XPath used in the propertyAlias are not shown directly in > that part of BPEL source code. I am afraid that a relatively naive > BPEL developer will forget all these XPath related faults can happen > in a <receive> with correlation. > > The programmer can still know what real issues are: the > correlationViolation fault details should expose the root cause. (e.g. > root cause : selectionFailure : the propertyAlias "/some/xpath" > defined "/.../../foo.wsdl" points to zero node) > > And, I would say having a higher-level fault/exception to hold the > details of underlying rootCause is very commonly used design pattern > (at least in Java API world). > > See: > http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Exception.html#Exception(java.lang.Throwable) > > > I hope that will help explaining my thoughts on this issue. > Thanks! > > Regards, > Alex Yiu > > Yaron Y. Goland wrote: > >> I am uncomfortable with the idea of obscuring a language fault with a >> correlation violation. The underlying fault is a language fault and >> for debugging and other purposes that is the fault that the >> programmer needs to address. As such I believe we should stick with a >> language fault in the case that a correlation set can't be initiated >> due to a language error. >> >> In general having a single fault that can cover multiple different >> fault conditions isn't a great idea. It significantly reduces the >> value of the fault because the programmer can't be sure what the real >> issue is. >> >> Yaron >> >> Alex Yiu wrote: >> >>> ----------------------------------------------------------- >>> In section "10.2 Defining and Using Correlation Sets" >>> >>> After the pargraph beginning with "If multiple correlation sets are >>> used >>> in a message activity", add a paragraph: >>> >>> "If an error occurs during executing a propertyAlias used by a >>> correlation set in a message activity, correlationViolation fault MUST >>> be thrown, instead of underlying query language related fault (e.g. >>> selectionFailure)." >>> >>> Enrich the description of "correlationViolation" fault in Appendix A: >>> >>> FROM: >>> "Thrown when the contents of the messages that are processed in an >>> invoke, receive, or reply activity do not match specified correlation >>> information. " >>> >>> TO: >>> "Thrown when the contents of the messages that are processed in an >>> invoke, receive, or reply activity do not match specified correlation >>> information OR when the initiate attribute do not match the state of >>> the >>> correlation information OR when a corresponding propertyAlias fails to >>> execute" >>> >>> ----------------------------------------------------------- >>> >>> Regards, >>> Alex Yiu >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]