Good points raised. My thinking was that with exceptions and causing a
bigger issue at runtime, hopefully Python processor developers would be
more likely to notice any issues during development, and the issues
wouldn't ever reach production. But the flip side is that there is a
risk of an unfo
I was thinking the same that first I also wanted to throw an
exception, but that would just trigger a rollback and we would retry
the flow file later. Still it is reasonable to at least write an error
message in the logs about the bad usage.
I also think that even though it is documented, it is no
Marton,
Sure, the idea of “an API should be easy to use correctly and hard to use
incorrectly” is certainly a great principle in API design.
But I’m not entirely sure that it applies here directly. The idea of “make it
hard to use incorrectly” doesn’t mean to throw an Exception
when used incorre
