search

bcmyers / num-format

A Rust crate for producing string representations of numbers, formatted according to international standards
Apache License 2.0
122 stars 22 forks source link

Maybe refactor error types #3

Closed bcmyers closed 5 years ago

BurntSushi commented 5 years ago

Since failure is a public dependency, you might consider dropping it. While the future is a bit unclear, I'm pretty sure it doesn't involve failure 0.1, so dropping it now will be easier for you than dropping it later. I don't think you need to replace it with anything either. You don't have that many error types, so writing out the impls by hand shouldn't be a burden.

(You might also consider flattening your module structure. A deeply nested crate with such a small API doesn't seem worth it IMO.)

loewenheim commented 5 years ago

Is there a reason apart from failure that Error and ErrorKind are distinct types?

BurntSushi commented 5 years ago

Splitting Error and ErrorKind is a very common pattern because it permits flexibility on the internal representation of an Error.

bcmyers commented 5 years ago

@BurntSushi - I agree with both of your suggestions. Thanks for the input! Here's a commit that flattens the module hierarchy (a breaking change, but better to get it over with early): link. I'll also factor out failure