[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue 185 - Some thoughts
I can see three ways of addressing the problem of how to enforce that faults have a 1:1 mapping to fault type, something already required in WSDL but not in BPEL generated faults. Note that all of these proposals provide ways to resolve issue 182. Proposal 1 - Require that static analysis be performed on a BPEL to confirm that any time a fault is thrown with data or a fault handler is specified with a fault name and a fault type that the type used in the throws/catches all use the same type with the same fault name. Also specify that it is explicitly legal to catch a fault by its name and without specifying its type (if any). In that case the fault data won't be accessible in the fault handler. In the previous case a rethrow would be able to access the data. Pro: Requires no change to our syntax and minimum change to our behavior. Con: If there is a canonical definition in some document some place of what type belongs with which fault name and the programmer screws it up and uses the wrong type there is no way for BPEL to catch the error. Proposal 2 - Introduce a way to declare an association between a fault name and a fault type, probably as an extension to process and certainly as something that can be imported. We could then explicitly allow faults to be caught by name even if they have data associated with them. As before rethrow will rethrow the data as well even if it wasn't explicitly caught. Pro: Provides a way to centrally define faults (via import) and enforce their consistent usage across multiple BPELs. Con: Requires extending import, introducing a new file format and probably extending process as well. Proposal 3 - Don't require that faults have a 1:1 mapping to fault types. Explicitly specify that it's legal to catch a fault just by its name even if it has data associated with it. Rethrow in the previous case will rethrow the fault's data even if the fault was only caught by its name. Pro: Requires the smallest possible change to the existing spec. Con: Fault usage is likely to become a foul mess as people associate random data with faults. Thoughts? Yaron
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]