Skip to content

Commit

Permalink
Stdout panic
Browse files Browse the repository at this point in the history
  • Loading branch information
retep998 committed Mar 25, 2015
1 parent 54a5d9d commit 1f9fd03
Showing 1 changed file with 10 additions and 9 deletions.
19 changes: 10 additions & 9 deletions 0000-template.md
Original file line number Diff line number Diff line change
@@ -1,29 +1,30 @@
- Start Date: (fill me in with today's date, YYYY-MM-DD)
- Start Date: 2015-03-25
- RFC PR: (leave this empty)
- Rust Issue: (leave this empty)

# Summary

One para explanation of the feature.
When calling `println!` it currently causes a panic if `stdout` does not exist. Change this to ignore this specific error and simply void the output.

# Motivation

Why are we doing this? What use cases does it support? What is the expected outcome?
On linux `stdout` almost always exists, so when people write games and turn off the terminal there is still an `stdout` that they write to. Then when getting the code to run on Windows, when the console is disabled, suddenly `stdout` doesn't exist and `println!` panicks. This behavior difference is frustrating to developers trying to move to Windows.

There is also precedent with C and C++. On both Linux and Windows, if `stdout` is closed or doesn't exist, neither platform will error when printing to the console.

# Detailed design

This is the bulk of the RFC. Explain the design in enough detail for somebody familiar
with the language to understand, and for somebody familiar with the compiler to implement.
This should get into specifics and corner-cases, and include examples of how the feature is used.
Change the internal implementation of `println!` `print!` `panic!` and `assert!` to not `panic!` when `stdout` or `stderr` doesn't exist. When getting `stdout` or `stderr` through the `std::io` methods, those versions should continue to return an error if `stdout` or `stderr` doesn't exist.

# Drawbacks

Why should we *not* do this?
Hides an error from the user which we may want to expose and may lead to people missing panicks occuring in threads.

# Alternatives

What other designs have been considered? What is the impact of not doing this?
* Make `println!` `print!` `panic!` `assert!` return errors that the user has to handle.
* Continue with the status quo and panic if `stdout` or `stderr` doesn't exist.

# Unresolved questions

What parts of the design are still TBD?
* Should `std::io::stdout` return `Err` or `None` when there is no `stdout` instead of unconditionally returning `Stdout`?

0 comments on commit 1f9fd03

Please sign in to comment.