It might be worth pointing out that this Rust:
#[derive(Debug)]
enum ConfigError {
Io(io::Error),
Parse(ParseIntError),
}
impl From for ConfigError {
fn from(err: io::Error) -> ConfigError {
ConfigError::Io(err)
}
}
impl From for ConfigError {
fn from(err: ParseIntError) -> ConfigError {
ConfigError::Parse(err)
}
}
fn read_config() -> Result {
Result::Ok(parse_int(read_config_file()?)?)
}
// given the following
fn parse_int(str: String) -> Result { ... }
fn read_config_file() -> Result { ... }
Is, in a sense, the equivalent of this Java:
int readConfig() throws IOException, ParseException {
return parseInt(readConfigFile());
}
// given the following
int parseInt(String str) throws ParseException { ... }
String readConfigFile() throws IOException { ... }
The reason i say that is that this:
throws IOException, ParseException
Is essentially a sum type. It says that if this method results in a failure value, it can fail with one of two types of failure values. It might not look like a new type, because in Java, types are almost always nominal, and this is structural, but that's what it is. I think that throw and catch clauses are the only place that Java will let you define an ad-hoc sum type. You have to use polymorphism everywhere else you want a variety of types.
Whereas in Rust, there are no structural sum types, and so the only way to make something resembling a sum type is:
enum ConfigError {
Io(io::Error),
Parse(ParseIntError),
}
Which means you also have to write the machinery to convert between the types.
I wonder if it would help to have a compiler- or library-defined From impl for all newtype enum variants (or all newtype structs more generally), that makes the variant from its argument. Or maybe it could be derived. It would wipe out a lot of this boilerplate.