There's actually multiple parts to this issue, one, as I think you pointed out Robert was whether or not we should default to a step failure if there is no work found to process. Should we always throw an exception, or should we not an assume anyone that wants to catch it will handle it themselves? Checking the item count seems possible, but it feels like a work around. It seems like it would be easier to ignore an exception than it would be to try and detect that nothing was done.
The other part of the problem is that, either way, all of the ItemReader implementations should behave the same way, it should be documented in the java docs as part of the contract. I'm afraid some of the readers would probably fail in open if there was no work found. For example, if a file that is configured to be read by a FlatFileItemReader doesn't exist, is that considered 'no work' or a failure? What if the file is empty? Should we dictate that the open method not throw an exception in these scenarios and that the reader simply return null on the first call? That seems somewhat brittle as well. It still seems easier to me to throw a no work found exception and have one point to say 'NoWorkFoundException means the job was successful' via configuration.