From: Christopher Dicely <cmdicely@...>
Date: 2011-05-01T19:16:26+09:00
Subject: Re: Is it usual/valid to extend custom classes under Errno module?

On Fri, Apr 22, 2011 at 11:15 AM, Iñaki Baz Castillo <ibc@aliax.net> wrote:
> Hi, I've coded a DNS library. When a DNS query fails my library
> doesn't raise an exception (as it's expensive) but instead returns a
> Symbol (more efficient):

This usually is a bad idea since performance on errors isn't really
something you usually need to optimize, and it ends up making the code
calling your library have to do ugly things like check return values
for errors.

> So returning a Symbol (in case of failure) is good as I can use it
> within a case/when statement.
>
> Another possibility would be returning an instance of a class,
> something like:
>
>  class EM::Udns::ErrorNoDomain <  EM::Udns::Error ; end
>  class EM::Udns::ErrorNoData     <  EM::Udns::Error ; end
>  class EM::Udns::ErrorTempFail  <  EM::Udns::Error ; end
>
>
> or I could extend Errno module:
>
>  class Errno::DnsNoDomain ; end
>  class Errno::DnsNoData     ; end
>  class Errno::DnsTempail    ; end

The Errno module provides a Ruby-ish way of dealing with OS error
values; so it doesn't really make sense for this use.

>
>
> In your opinnion, which is the most elegant way? any other
> suggestion?

The most elegant way is to raise an exception (which, ideally, should
be an instance of a unique exception class for each of your error
conditions.) This makes the code calling your library functions
cleaner, since it doesn't have to check return values for errors,
allowing a cleaner separation before the normal path and the error
path.