There are two situations in XPathFilteringStage where an XPathExpressionException is caught and essentially ignored:
If the expression fails to compile, an error is logged and no filtering is performed:
If an evaluation of the expression throws, the individual item is filtered out of the collection:
I think this is the wrong approach in both cases; if the expression is faulty at runtime, this should be a StageProcessingException as it indicates that the Stage has been misconfigured.
It would actually have been better in some ways to compile the expression in the stage's initializer, as that would turn at least one of these issues into a ComponentInitializationException, which I think would have been an improvement. Unfortunately, none of the objects in the XPath API are thread-safe or reentrant, so this would have required synchronized access to the field.