Within a CheckEquilibriumSpec function, there is a call to GetPresentPhases. What should happen if GetPresentPhases fail or return empty "phaseLabels"? Should CheckEquilibriumSpec returns "isSupported" as FALSE or should it return an exception as ECapeUnknown? or should it return both "isSupported" as FALSE and an exception.

I have seen a case of GetPresentPhases call failing because of no SetPresentPhases made before calling CheckEquilibriumSpec. The revision of Thermo 1.1 specification mentions that SetPresentPhases has to be made before calling CheckEquilibriumSpec but not all PMEs are compliant yet with this sequence. If GetPresentPhases fails within CheckEquilibriumSpec, may GetPresentPhases return ECapeBadInvokOrder or would this be too presomptuous?

I have seen these cases as well, and it is easy to make this mistake. If you want to check whether a certain flash is supported, you do not always think of checking whether it is supported for a certain set of phases.

However, it is proper to set the phases before CheckEquilibriumSpec. An implementation that actually checks the phases (some implementations do not bother checking this) could choose whether to return not supported or an error I suppose.

ECapeBadInvokation order would indeed be making an assumption, as the CheckEquilibriumSpec cannot see whether SetPresentPhases was not called, or was called with an empty list.

I am not in favor of a set of possible responses to a situation.

When a function raises an exception, my understanding is that the code having called this method should not bother getting values from the out auguments of the function so returning both an exception and "isSupported" as FALSE does not make really any sense. Raising an exception should be interpreted as returning FALSE whatever the actual value of "isSupported". That is a first point I would like clarification on.

Secondly, I think that returning an exception when GetPresentPhases fails within CheckEquilibriumSpec or when GetPresentPhases returns a empty set of "phaseLabels" is too strong a measure. It seems to me sufficient to return that "isSupported" is at FALSE. CheckEquilibriumSpec may log a message about the behaviour of GetPresentPhases that would appear in some trace on the PME side. That seems sufficient to me. It is the result of CheckEquilibriumSpec that matters, not the specifics. Should a PME not use SetPresentPhases before calling CheckEquilibriumSpec, getting an exception because of GetPresentPhases won't make the PME redo the sequence with a SetPresentPhases at first. The issue with GetPresentPhases can always be logged with OATS/COLTT when it is a matter of debugging the sequence if needed.

Agreed: an exception should indicate the method is not supported or support cannot be checked.

Just returning "not supported" may leave the caller (implementor) wondering why exactly a flash that is expected to be supported is not. E.g. if the caller asks whether the package supports a TP flash, the expected answer is yes. If the answer is no, it would be helpful if the package returns an error along the lines: 'cannot perform flashes without phases present'. Not to the end user, but surely to the implementors, this would be of value.