[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 219 - proposal to vote
I would also point out that fault/exception encapsulation is all well and good when you have an encapsulation mechanism. We do not. Yaron Prasad Yendluri wrote: > > > Hi Alex, > > I understood what you are proposing. I am not convinced that this is a > good approach here. > IMO a simple cautionary note is better solution here than an > encapsulation of all possible faults (here) into something different. > > Regards, Prasad > > Alex Yiu wrote: > > > Prasad, > > > > First of all, I hope most people would recognize that fault/exception > > encapsulation is a valid design pattern. > > > > The question is when to apply this fault encapsulation concept vs when > > to keep the original faults. > > > > In this case, I still tend to think it is beneficial to users to apply > > fault encapsulation here, especially in the light of engine-managed > > correlation. > > > > That is, the same kind of correlationViolation fault should be thrown, > > regardless whether the engine-managed correlation header is mal-formed > > or the xpath in propertyAlias selection points to zero node in message > > payload. > > > > I hope this may convince you better. > > Thanks! > > > > Regards, > > Alex Yiu > > > > Prasad Yendluri wrote: > > > >> 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 > >>>> > >>>> > >>>> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe from this mail list, you must leave the OASIS TC that > >> generates this mail. You may a link to this group and all your TCs > >> in OASIS > >> at: > >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]