On 13/06/2014 12:15, Michael McMahon wrote:
To be honest, the test doesn't/(can't easily) check if a flow has been
created. So, in practice
a success return code doesn't prove that everything is working.
Exercising the code at least
is a basic smoke test. If we add a new exception then maybe w
On 13/06/14 12:10, Alan Bateman wrote:
On 13/06/2014 11:49, Michael McMahon wrote:
Okay. I can see the reasoning why supportedOptions should refer to
the platform rather than the process/instance
running. We could consider adding a sub-class of IOException for
permission related failures, but
On 13/06/2014 11:49, Michael McMahon wrote:
Okay. I can see the reasoning why supportedOptions should refer to the
platform rather than the process/instance
running. We could consider adding a sub-class of IOException for
permission related failures, but I'm not proposing
to do that here. For
On 13/06/14 10:08, Chris Hegarty wrote:
On 12/06/14 21:04, Michael McMahon wrote:
On 12/06/14 20:35, Alan Bateman wrote:
On 12/06/2014 20:15, Michael McMahon wrote:
It would be possible to change the error back, but what about
supportedOptions() - what should
that return? It doesn't seem ri
On 12/06/14 21:04, Michael McMahon wrote:
On 12/06/14 20:35, Alan Bateman wrote:
On 12/06/2014 20:15, Michael McMahon wrote:
It would be possible to change the error back, but what about
supportedOptions() - what should
that return? It doesn't seem right that it would include an option
that
