Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Convert all errors to use error-chain!{..} #17

Closed
bluejekyll opened this issue Jun 15, 2016 · 4 comments
Closed

Convert all errors to use error-chain!{..} #17

bluejekyll opened this issue Jun 15, 2016 · 4 comments
Assignees
Labels

Comments

@bluejekyll
Copy link
Member

This should simplify error handling in Trust-DNS

@bluejekyll bluejekyll self-assigned this Jun 15, 2016
@dckc
Copy link

dckc commented Nov 6, 2016

There are various uses of .expect() in named.rs for things that are ordinary runtime error conditions (I/O Error loading the config file, bad zone name, ...). Shouldn't panic!() and hence .expect() be limited to bugs? i.e. design-time problems?

I have to admit I can't figure out an alternative. I got the impression

fn load_zone(zone_dir: &Path, zone: &ZoneConfig) -> Result<Authority, String> {
  let zone_name: Name = zone.get_zone().expect("bad zone name");

should become

fn load_zone(zone_dir: &Path, zone: &ZoneConfig) -> Result<Authority, String> {
  let zone_name: Name = try!(zone.get_zone().chain_err("bad zone name"));

but it doesn't compile, even with use trust_dns::error::ParseChainErr added.

p.s. I'm commenting here rather than raising a new issue because I'm not sure whether this is as-designed or not.

@bluejekyll
Copy link
Member Author

I'll try and answer this question as best I can. First on the usage of expect/unwrap/panic in named. This is a top level binary. I've only expected it to be run through the main() method in binary form. To me, this means that given that any error in loading config will end up causing the application to exit abnormally, is fine. For anyone trying to use this as I library, where unwraps/expects should all be guarded against, I never intended them to call into named.rs (is that even possible?), but through the lib.rs and the trust_dns::server module.

Now, we could clean this up in named.rs for the purposes of outputting cleaner errors to end users, that's probably a good goal at some point, but that hasn't been a top priority for me. I'd absolutely accept patches to clean that up!

As to your issue with the chain_err(...) conversion issue, the Result probably has to be mapped to a String with map_err(...). Even though I've changed everything to use error-chain everywhere, I haven't actually used chain_err(...) enough to know exactly what the issue is there.

@dckc
Copy link

dckc commented Nov 6, 2016

OK, thanks for clarifying: panic!() from named should probably be cleaned up for nicer UX, though it's not critical. That's the way I look at it too.

Here's hoping for time to look into it further.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants