fix(docs): Handle errors, rather than using `unwrap`, in examples

[LeoniePhiline]

This PR

Fixes #49

Notes

A note regarding the from_path* example changes

I simplified these examples, as they did not plainly show off usage and were somewhat nonsensical:

• They used an external crate, which was unnecessary.
• They tried getting the home directory, then insinuated joining it with an absolute path.
• They gave the false impression absolute paths were necessary, while relative paths are just as suitable.
• They used .as_path() for a method accepting AsRef<Path>, which PathBuf implements.
• The docs don't actually make clear what's the difference between from_filename* and from_path* (which is in fact the recursive lookup in parent directories). I'll open a separate issue about that to keep the PR clean.

A note regarding dotenv_override example changes

• Replaced use by fully qualified name to keep consistent with the other dotenv* examples.
• Removed .ok() for consistency with the dotenvy::dotenv example.

[github-actions[bot]]

[allan2]

For most of these, I prefer the original. See this comparison:

Original

dotenvy::from_filename("custom.env").unwrap();

Suggested

fn main() -> Result<(), Box<dyn std::error::Error>> {
dotenvy::from_filename("custom.env")?;
    Ok(())
}

The original is more legible for illustrating the usage of from_filename().

I can see ? being preferable to unwrap() in lengthier examples that are often copied and pasted, but that isn't usually the case here.

[LeoniePhiline]

@allan2 You're missing here that rustdoc renders this as:

dotenvy::from_filename("custom.env")?;

The entire code block is being run as a test. Lines prefixed with # are removed from user-facing documentation.

This is common practice, as well as best practice in Rust projects.

I would recommend you run cargo doc --open and have a look at the generated documentation.

---

I can see ? being preferable to unwrap() in lengthier examples that are often copied and pasted, but that isn't usually the case here.

This isn't at all related to lengthiness, but about proliferating proper error handling.

I am very sure the examples shown in the dotenvy documentation are copy-pasted very, very often.

[allan2]

My apologies, I did miss that.

This PR looks good to me!