Error cleanup: standard pattern for I/O errors and enum naming

[sffc]

I attempted three different patterns for I/O errors in three different modules. I settled on the one that uses .map_err(|e| (e, &path)) because it seems clean with minimal boilerplate and easy to port between modules.

[zbraniecki]

I'm leaning toward the idea that most errors are "internal" and relevant only within the scope of a module inside a crate (say, plurals::operands::Error or plurals::parser::Error).
Usually, each crate will have one error that is "public" in a sense of - when a regular user uses our crate, they will have to write some handling of that error either by having functions that return it, or converting that error to their error.

In that case, I suggest to give it a unique name, so that users don't end up with:

use icu_datetime::Error as DateTimeError;
use icu_pluralrules::Error as PluralRulesError;
...

but I'm ok also just naming all errors Error and expecting it for now and then maybe we'll get to the point where we'll rename the public one later.

This looks good for me for now.

[filmil]

I'm leaning toward the idea that most errors are "internal" and relevant only within the scope of a module inside a crate (say, plurals::operands::Error or plurals::parser::Error).
Usually, each crate will have one error that is "public" in a sense of - when a regular user uses our crate, they will have to write some handling of that error either by having functions that return it, or converting that error to their error.

In that case, I suggest to give it a unique name, so that users don't end up with:

use icu_datetime::Error as DateTimeError;
use icu_pluralrules::Error as PluralRulesError;
...

but I'm ok also just naming all errors Error and expecting it for now and then maybe we'll get to the point where we'll rename the public one later.

This looks good for me for now.

[filmil]

(disregard, wrong click)

[sffc]

Currently I use the name Error internally but rename it when exporting it in the lib.rs file.

[filmil]

Currently I use the name Error internally but rename it when exporting it in the lib.rs file.

FWIW, using renamed "long form" (DateTimeError) errors is consistent with our style guide.
It also (still) makes sense to me to use pithy names (like Error) for types that the user isn't going to interact with directly.

I think this is consistent with the observation that people prefer to type DateTimeError to datetime::Error, and that if we don't match that preference users are simply going to be renaming thing. So we meet the users where they are, and give them properly named types from the get-go.