Define behavior for task/flow protocol violations

[leonoel]

Currently the operator implementation expects tasks and flows to be compliant with the specification, otherwise the behavior is undefined.

This happens in the following situations :

• programmer mistakes, e.g an operator receives a non-flow where it should be a flow. Not supposed to happen in production but very common during dev time, good reporting could improve user experience.
• abnormal conditions such as OutOfMemoryError thrown by a callback. Not supposed to happen in production either, but if/when it does the program should do its best to propagate and report the error.

[mjmeintjes]

This would be a major improvement, as currently these types of bugs are very difficult to diagnose and prevent.

Some things to think about:

• throw an exception as soon as I try to m/? something that is not a task
• whether to allow (m/? nil) - it would simplify things if that just returned nil, but I'm not sure about the implications of that
• allow some way of printing warnings when running m/? outside a process block

[mjmeintjes]

Here's an example of invalid behavior:

These throw exceptions as expected:

  (m/? (m/seed [1 2]))

  (m/? (m/ap))

  (m/? (m/ap (m/?> (m/seed [1 2]))))

I would expect the following to throw an exception, but it just hangs instead. This can be difficult to diagnose when happens deep inside a process.

(m/? (m/ap (m/?= (m/seed [1 2]))))