I think that the state diagram says that it’s not allowed.
However, I don’t think that each implementation should check that, as
that would require additional state and code in each operator that
should not be needed (if everybody sticks to the contract).
If we want to check that the contract is maintained we should do that
either in the unit tests or by introducing a wrapper that checks the
contract on top of the operator itself. This wrapper could then be added
during plan generation if indicated by a user (e.g. by setting a flag).
My 2c,
Till
On 9 Dec 2015, at 10:56, abdullah alamoudi wrote:
There seems to be something missing here which is the legal function
calls
that can be made in each state. For example:
1. Is it legal to call open() on an open instance of IFrameWriter? If
not,
then is it the responsibility of the IFrameWriter to throw an
exception in
that case
?
2. Is it legal to call close() on a closed instance of IFrameWriter?
If
not, then again, who's responsibility is it to throw an exception in
that
case?
3. Is it legal to call fail() on a failed instance of IFrameWriter? If
not,
then again, who's responsibility is it to throw an exception in that
case?
I am asking this because I think that is happening in some places in
the
code already.
Should we allow that?
Abdullah.
Amoudi, Abdullah.
On Tue, Dec 8, 2015 at 11:56 PM, Mike Carey <[email protected]> wrote:
+1
On 12/8/15 5:43 PM, Till Westmann wrote:
Hi,
When improving test coverage we noticed, that there are some
inconsistencies wrt. state management and transitions in different
implementations of IFramewriter. These inconsistencies cause a
number of
test failures - especially when testing error conditions. Ian has
written
up a document [1] on the current contract (which is unfortunately
not
consistently implemented) and on an alternate contract that we have
discussed.
We currently believe that the alternate contract would be preferable
as
there is more similarity in the approach to handling errors during
open()
or nextFrame().
Our proposal is to
1) Adopt the alternate contract and document it in
a) the IFramewriter javadoc and
b) a design document.
2) Implement new operators according to the alternate contract.
3) Add mock-based unit tests (e.g. using Mockito [2]) for new
operators
that verify that the contract is maintained.
4) Add mock-based using test for existing operators as bugs are
found and
fixed.
Please take a look at the document and tell us, what you think about
the
contract and the approach.
Thanks,
Abdullah, Ian, Yingyi, and Till
[1]
https://docs.google.com/document/d/1QJ8X7QFMMax5D5k9RVje6hoNr_SNZSW9Oshzv7DpcQw/edit?usp=sharing
[2] http://mockito.org/
