std::io: New ErrorKind value InvalidData #25246

mzabaluev · 2015-05-09T16:03:09Z

This takes the cases from InvalidInput where a data format error
was encountered. This is different from the documented semantics
of InvalidInput, which more likely indicate a programming error.

Fixes rust-lang/rfcs#906

rust-highfive · 2015-05-09T16:03:17Z

r? @pcwalton

(rust_highfive has picked a reviewer for you, use r? to override)

mzabaluev · 2015-05-09T16:03:50Z

This is a PR for rust-lang/rfcs#906.

mzabaluev · 2015-05-09T16:06:25Z

To bikeshed a bit more, I'd rename InvalidInput to InvalidParam, but it's perhaps too late for this breaking change.

Stebalien · 2015-05-11T15:00:10Z

src/libstd/ffi/c_str.rs

@@ -239,7 +239,7 @@ impl fmt::Display for NulError {
 #[stable(feature = "rust1", since = "1.0.0")]
 impl From<NulError> for io::Error {
    fn from(_: NulError) -> io::Error {
-        io::Error::new(io::ErrorKind::InvalidInput,
+        io::Error::new(io::ErrorKind::InvalidData,


This should probably stay as-is. CString::new returns a NulError when its argument (input) contains a null.

The character data may have come from outside the program. In general, it's not a programming error for strings to contain null bytes, so to me it belongs in the same class of data conversion failures as, say, encountering malformed UTF-8 in an input operation that reads to a string.

alexcrichton · 2015-05-12T20:50:19Z

I'm not sure I personally understand the distinction here, it seems like selecting one or the other can be ambiguous from time to time and the distinction may not actually carry much weight in the wild. Could you elaborate a little more on how these two are distinct and how they should be interpreted separately?

alexcrichton · 2015-05-12T20:50:27Z

cc @aturon

mzabaluev · 2015-05-13T13:16:09Z

@alexcrichton Other than data format errors, InvalidInput is currently used for e.g. seeking to an invalid offset. The latter is clearly a programming error, while malformed data can occur on input of a correctly working program.

alexcrichton · 2015-05-13T15:54:07Z

Hm I guess to me those seem like very similar classes of errors as they're both "invalid inputs" to the function. I think that InvalidData as an error type for data being produced makes a little more sense to me, for example read_to_string returning InvalidData can be rationalized in my head a bit more, but I don't personally see a difference between seeking to a negative offset and providing a string with an interior nul byte.

mzabaluev · 2015-05-14T09:53:00Z

read_to_string may be reading from a file, in which case InvalidInput arises due to no fault of the program.

mzabaluev · 2015-05-14T15:34:41Z

#25406 is an alternative change where, conversely, the invalid-parameter cases are reclassified from InvalidInput to InvalidParam.

aturon · 2015-05-14T16:29:50Z

FWIW, I agree that it would be good to have distinct errors for "You passed in arguments that broke the contract" versus "The OS returned some data that was not in the expected form".

I'm not in love with InvalidData for the latter, though; it's a bit too vague. Maybe InvalidOutput?

I also agree with others that the CString related errors should stay as InvalidInput since they represent contract violations on the Rust side.

bluss · 2015-05-14T22:23:09Z

I'm not in love with InvalidData for the latter, though; it's a bit too vague. Maybe InvalidOutput?

When we are decoding a stream of text, it's invalid input to the program, not output.

aturon · 2015-05-14T23:11:06Z

@bluss

I'm not in love with InvalidData for the latter, though; it's a bit too vague. Maybe InvalidOutput?

When we are decoding a stream of text, it's invalid input to the program, not output.

The error variant is relative to the operation being performed, not the broader context of the program. We need the pair of variants to clearly signify whether the problem was with the arguments passed to the operation (InvalidInput) or with the data produced by the operation (hence InvalidOutput).

Following some bikeshedding on PR rust-lang#25246.

mzabaluev · 2015-05-17T10:57:11Z

I have updated the branch, thanks for your input. In my personal opinion, there is still potential for confusion between InvalidInput and InvalidOutput. I'd rename the former to clearly mean "invalid argument used for the operation", but I don't see how it can be done in a backwards-compatible way; the whole issue does not seem big enough to demand more drastic changes.

bluss · 2015-05-17T11:38:26Z

My head is spinning. Run this past a bit more people to see what they think? Why do we use the terms Input / Output when we don't mean I/O? 😄 InvalidParameter, InvalidArgument, anything like that is better. W.r.t if data we process using the APIs is regarded as output from something else or input to us, or the reverse, that I don't know. I suggest just saying data for that, hence InvalidData.

aturon · 2015-05-18T22:52:02Z

@bluss

The usage here is just the notion of arguments being "input" to a function, and the results it produces being its "output".

Admittedly, InvalidArgument and InvalidResult would probably be more clear, but that would require a breaking change.

aturon · 2015-05-19T00:39:38Z

OK, after talking to @alexcrichton for a while, and stewing a bit more on the comments here, I think @bluss is right and the names InvalidInput and InvalidOutput, while technically meaningful, are likely to be too confusing in this context. Given that we're committed to InvalidInput, I'm now on board with InvalidData as the originally proposed complement.

bluss · 2015-05-19T01:11:23Z

I would be happier. Consider that we use InvalidOutput/InvalidData for the case when stdin contains non-utf-8 data.

mzabaluev · 2015-05-21T07:40:38Z

Rebased and condensed into one commit.

alexcrichton · 2015-05-26T16:06:20Z

src/libstd/io/error.rs

@@ -95,6 +95,9 @@ pub enum ErrorKind {
    /// A parameter was incorrect.
    #[stable(feature = "rust1", since = "1.0.0")]
    InvalidInput,
+    /// Invalid data encountered.
+    #[stable(feature = "rust1", since = "1.0.0")]


This stability tag should now say 1.1.0, and the feature name can be something like io_invalid_data.

Could you also expand the docs here a bit to clarify what InvalidData means with respect to InvalidInput?

Sorry, I have copy-pasted it without thinking.

This takes the cases from InvalidInput where a data format error was encountered. This is different from the documented semantics of InvalidInput, which more likely indicate a programming error.

mzabaluev · 2015-05-29T19:39:12Z

Updated and rebased the commit, now with a more descriptive doc text and corrected stability attribute.

alexcrichton · 2015-05-29T20:41:44Z

src/libstd/io/error.rs

+    /// Unlike `InvalidInput`, this typically means that the operation
+    /// parameters were valid, however the error was caused by malformed
+    /// input data.
+    #[stable(feature = "io_invalid_data", since = "1.1.0")]


Gah oops, sorry but I forgot we've entered 1.2 territory at this point, so this should actually be 1.2 instead of 1.1. Other than that though this looks good to me!

mzabaluev · 2015-05-31T03:34:30Z

Note that this is, strictly speaking, a breaking change: error-handling code that matches for InvalidInput may work differently between 1.0 and the version where this change lands.
This means it may need to be deferred to 2.0, when InvalidInput can also be renamed.

alexcrichton · 2015-06-01T16:49:59Z

@bors: r+ 0ad019f

bors · 2015-06-01T17:18:21Z

⌛ Testing commit 0ad019f with merge 8ffe552...

This takes the cases from `InvalidInput` where a data format error was encountered. This is different from the documented semantics of `InvalidInput`, which more likely indicate a programming error. Fixes rust-lang/rfcs#906

bors · 2015-06-01T18:57:48Z

💔 Test failed - auto-linux-64-opt

alexcrichton · 2015-06-01T20:27:45Z

@bors: retry

On Mon, Jun 1, 2015 at 11:57 AM, bors notifications@github.com wrote:

[image: 💔] Test failed - auto-linux-64-opt
http://buildbot.rust-lang.org/builders/auto-linux-64-opt/builds/5172

—
Reply to this email directly or view it on GitHub
#25246 (comment).

bors · 2015-06-01T21:36:28Z

⚡ Previous build results for auto-linux-32-nopt-t, auto-linux-64-nopt-t, auto-linux-64-x-android-t, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt are reusable. Rebuilding only auto-linux-32-opt, auto-linux-64-opt...

alexcrichton · 2015-06-01T23:12:50Z

@bors: retry clean force

This takes the cases from `InvalidInput` where a data format error was encountered. This is different from the documented semantics of `InvalidInput`, which more likely indicate a programming error. Fixes rust-lang/rfcs#906

bors · 2015-06-01T23:12:53Z

⌛ Testing commit 0ad019f with merge 613e57b...

bors · 2015-06-02T02:08:16Z

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt

rust-highfive assigned pcwalton May 9, 2015

Stebalien reviewed May 11, 2015
View reviewed changes

alexcrichton assigned alexcrichton and unassigned pcwalton May 12, 2015

mzabaluev mentioned this pull request May 14, 2015

std::io: new ErrorKind value InvalidParam #25406

Closed

mzabaluev force-pushed the io-invalid-data branch from cae27c9 to 999ffea Compare May 17, 2015 10:52

mzabaluev added a commit to mzabaluev/rust that referenced this pull request May 17, 2015

Renamed InvalidData to InvalidOutput

c7212ea

Following some bikeshedding on PR rust-lang#25246.

mzabaluev force-pushed the io-invalid-data branch from 999ffea to 7d50cbc Compare May 21, 2015 07:38

alexcrichton reviewed May 26, 2015
View reviewed changes

alexcrichton added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label May 26, 2015

std::io: New ErrorKind value InvalidData

1d67cef

This takes the cases from InvalidInput where a data format error was encountered. This is different from the documented semantics of InvalidInput, which more likely indicate a programming error.

mzabaluev force-pushed the io-invalid-data branch from 7d50cbc to 1d67cef Compare May 29, 2015 19:33

alexcrichton reviewed May 29, 2015
View reviewed changes

std::io: bump the stability tag on ErrorKind::InvalidData to 1.2.0

0ad019f

bors merged commit 0ad019f into rust-lang:master Jun 2, 2015

tbu- mentioned this pull request Aug 24, 2016

Implement more traits for std::io::ErrorKind #35911

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

std::io: New ErrorKind value InvalidData #25246

std::io: New ErrorKind value InvalidData #25246

mzabaluev commented May 9, 2015

rust-highfive commented May 9, 2015

mzabaluev commented May 9, 2015

mzabaluev commented May 9, 2015

Stebalien May 11, 2015

mzabaluev May 13, 2015

alexcrichton commented May 12, 2015

alexcrichton commented May 12, 2015

mzabaluev commented May 13, 2015

alexcrichton commented May 13, 2015

mzabaluev commented May 14, 2015

mzabaluev commented May 14, 2015

aturon commented May 14, 2015

bluss commented May 14, 2015

aturon commented May 14, 2015

mzabaluev commented May 17, 2015

bluss commented May 17, 2015

aturon commented May 18, 2015

aturon commented May 19, 2015

bluss commented May 19, 2015

mzabaluev commented May 21, 2015

alexcrichton May 26, 2015

mzabaluev May 29, 2015

mzabaluev commented May 29, 2015

alexcrichton May 29, 2015

mzabaluev commented May 31, 2015

alexcrichton commented Jun 1, 2015

bors commented Jun 1, 2015

bors commented Jun 1, 2015

alexcrichton commented Jun 1, 2015

bors commented Jun 1, 2015

alexcrichton commented Jun 1, 2015

bors commented Jun 1, 2015

bors commented Jun 2, 2015

std::io: New ErrorKind value InvalidData #25246

std::io: New ErrorKind value InvalidData #25246

Conversation

mzabaluev commented May 9, 2015

rust-highfive commented May 9, 2015

mzabaluev commented May 9, 2015

mzabaluev commented May 9, 2015

Stebalien May 11, 2015

Choose a reason for hiding this comment

mzabaluev May 13, 2015

Choose a reason for hiding this comment

alexcrichton commented May 12, 2015

alexcrichton commented May 12, 2015

mzabaluev commented May 13, 2015

alexcrichton commented May 13, 2015

mzabaluev commented May 14, 2015

mzabaluev commented May 14, 2015

aturon commented May 14, 2015

bluss commented May 14, 2015

aturon commented May 14, 2015

mzabaluev commented May 17, 2015

bluss commented May 17, 2015

aturon commented May 18, 2015

aturon commented May 19, 2015

bluss commented May 19, 2015

mzabaluev commented May 21, 2015

alexcrichton May 26, 2015

Choose a reason for hiding this comment

mzabaluev May 29, 2015

Choose a reason for hiding this comment

mzabaluev commented May 29, 2015

alexcrichton May 29, 2015

Choose a reason for hiding this comment

mzabaluev commented May 31, 2015

alexcrichton commented Jun 1, 2015

bors commented Jun 1, 2015

bors commented Jun 1, 2015

alexcrichton commented Jun 1, 2015

bors commented Jun 1, 2015

alexcrichton commented Jun 1, 2015

bors commented Jun 1, 2015

bors commented Jun 2, 2015