Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spurious behavior of Display::fmt errors #31879

Closed
Xion opened this issue Feb 25, 2016 · 1 comment
Closed

Spurious behavior of Display::fmt errors #31879

Xion opened this issue Feb 25, 2016 · 1 comment

Comments

@Xion
Copy link

Xion commented Feb 25, 2016

I've encountered a surprising and undocumented behavior of Display::fmt, which I was advised on #rust to file an issue about.

Given the code (http://is.gd/iRjVCG):

use std::fmt;
use std::io::{self, Write};


struct Foo;

impl fmt::Display for Foo {
    fn fmt(&self, _: &mut fmt::Formatter) -> fmt::Result {
        Err(fmt::Error)
    }
}


fn main() {
    write!(io::stdout(), "{} {} {}", 1, Foo, "bar").unwrap();
}

the expected result, as far as I can tell, is a panic. Instead it just prints 1, apparently terminating at the formatting error of Foo but otherwise suppressing the error and returning Ok from write!.

(I encountered this behavior in the wild on current 1.6 stable. The above is a minimal example that reproduces it).

If this is intended, I find it extremely surprising. For one, this would mean there is no reliable way to distinguish formatting errors (Err returned from Display::fmt) from Display implementations that simply return an empty string in the simple format!("{}", ...) cases.

But if that's the intended behavior, then this probably qualifies as a documentation bug or omission, because there is no explanation what is the effect of returning Err from Display:::fmt.

@alexcrichton
Copy link
Member

Hm I thought we already had an issue for this, but I can't seem to find it now. The problem here is that we assume that fmt::Error is never "just generated", but rather it always originates from the underlying writer returning an error. This is probably a relatively easy fix in the code.

Manishearth added a commit to Manishearth/rust that referenced this issue Feb 26, 2016
…xcrichton

Make sure formatter errors are emitted by the default Write::write_fmt

Previously, if an error was returned from the formatter that did not
originate in an underlying writer error, Write::write_fmt would return
successfully even if the formatting did not complete (was interrupted by
an `fmt::Error` return).

Now we choose to emit an io::Error with kind Other for formatter errors.

Since this may reveal error returns from `write!()` and similar that
previously passed silently, it's a kind of a [breaking-change].

Fixes rust-lang#31879
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants