Saxon

This message is written by the StandardErrorListener, which is the default ErrorListener. You can substitute your own ErrorListener that does something which is more to your taste (method XQueryEvaluator.setErrorListener). Alternatively, you can redirect the output of the StandardErrorListener to a different destination (by default it goes to System.err).

I guess Saxon's design in this area can be traced back to the JAXP APIs, which require errors to be notified to an ErrorListener. Indeed, the ErrorListener interface is the one defined by JAXP. We could have chosen to do it differently when we designed the s9api interface, but the existing model seemed to work well enough. The introduction of try/catch in 3.0 is putting it under a little bit of strain, so perhaps it's time for a review, but it will be hard to please everyone, and any change is likely to be very disruptive to existing applications. Arguably the ErrorListener is more suited for an environment in which errors are recoverable, which was perhaps the thinking of the JAXP designers; or perhaps they were simply copying the SAX design which is designed to report multiple errors during XML parsing and validation.

Thank you for the detailed explanation. My objection however is not to the path that the message follows but to the validity of the message as such. I do not see the situation which I describe as an error in the API or in the script which it is executing. This is why I feel that the API should not own the situation to the degree of crying out loud about it. It may possibly be argued that the situation is in a sort of twilight zone from the standpoint of ownership and if this is your position then it will prevail for obvious :) reasons. In such case please at least bear in mind the existence of different positions if/when the time comes for redesign.