Convert all errors to use error-chain!{..} about hickory-dns

[bluejekyll]

https://users.rust-lang.org/t/announcing-error-chain-a-library-for-consistent-and-reliable-rust-error-handling/6133

[dckc]

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]

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]

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.