Add UnexpectedOutput to IoErrorKind (or something similar)

[carllerche]

This would help support any higher level IO abstractions, such as parsers, or wrappers around process calls, etc...

For example, an abstraction that shims execing sub processes and handling the result could fail w/ UnexpectedOutput if the subprocess did not provide a valid result.

Another use-case, when wrapping an IO stream w/ an HTTP parser (or any higher level protocol), it would be nice to just return an IO like API, but when failing to parse, there is no good IoErrorKind to describe failing to handle the output in the abstraction.

[alexcrichton]

I've been using InvalidInput for situations such as this, do you think that this is distinct enough from that kind?

[carllerche]

InvalidInput implies to me that what I provided the API was incorrect. UnexpectedOutput would be the reverse.

Whether they are distinct enough, I don't know. I didn't think it was appropriate to use InvalidInput.

[steveklabnik]

Triage: no change

[Mark-Simulacrum]

io::ErrorKind::InvalidData has the following description:

Data not valid for the operation were encountered.

Unlike InvalidInput, this typically means that the operation parameters were valid, however the error was caused by malformed input data.

For example, a function that reads a file into a string will error with InvalidData if the file's contents are not valid UTF-8.

I think this fits the described UnexpectedOutput, so can this be closed?