Listing 9-5 may be unrealistic and therefore confusing

[Christoph Groth]

• I have searched open and closed issues and pull requests for duplicates, using these search terms:

  • listing 9-5
  • example 9.2
  • 9.2 confusing

• I have checked the latest main branch to see if this has already been fixed, in this file:

  • listings/ch09-error-handling/listing-09-05/src/main.rs
  • src/ch09-02-recoverable-errors-with-result.md

URL to the section(s) of the book with this problem:

https://doc.rust-lang.org/book/ch09-02-recoverable-errors-with-result.html#matching-on-different-errors

Description of the problem:

The example of listing 9-5 first tries to open a file for reading. If this fails, it tries to create the file for writing. The resulting File object is therefore either open for reading, or for writing. I find it difficult to imagine similar code in a real program. What would be a realistic action to be performed with the variable greeting_file?

Sure, I see that the point of this example is to demonstrate nested error handling. But I think that it should be possible to come up with an example that is not confusing.

Suggested fix:

I might be missing some subtlety here. In that case, I suggest adding a brief explanation to the text.

If my analysis is correct, I suggest modifying the example. An alternative listing could try to open a file "hello.txt" for reading. If this fails, it would try to open the file "default.txt" for reading instead. IMHO this would be a more realistic example demonstrating the same principles.

[Sambit Senapati]

I might have misunderstood, but I have encountered situations where a program needs to interact with a configuration file or a user's data and the file is not there. So the Logic is: If the file already exists, the program reads its content; otherwise, it creates the file and allows the user to input the required information.

[Christoph Groth]

Reading or writing depending on whether the file exists is a viable scenario. However the code snippet in question IMHO does not implement it in a useful way, not even as a toy example.

The value of the outer match block is a std::fs::File that is either open for reading or for writing. However it is not straightforward and not recommended to check whether a file object is open for writing or not.

One would either have to perform the reading/writing inside the match block, but then why even return the file object and not just the config? The other possibility would be to return a flag that signals the intent, but why duplicate a conditional structure that is already present?

I think that having a file object that is either open for writing or for reading at one point in a program is very uncommon and possibly a bad pattern. Since the intention here is merely to illustrate error handling, I think that a less contrived example would be helpful.

[Carol (Nichols || Goulding)]

Many of the examples in the book are unrealistic because it's hard to make a realistic example in a concise manner.