From: "Iñaki Baz Castillo" <ibc@...>
Date: 2011-05-01T21:22:58+09:00
Subject: Re: Is it usual/valid to extend custom classes under Errno module?

2011/5/1 Christopher Dicely <cmdicely@gmail.com>:
> 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.

Hi, in my tests raising and capturing an exception is 100 times more
expensive (or more) than returning a value. Also take into account
that my DNS library works on top of EventMachine:

  https://github.com/ibc/em-udns

So it's asyncrhonous and non-blocking. This means that ater doing a
DNS query I get the result in a callback (a callback and a errback in
case the domain or the resource record doesn't exist). This means
that, even if I want, I cannot raise an exception.

I use this DNS library in a SIP server on top of EventMachine I'm
coding. A SIP server receives lots of requests (i.e. telephony calls)
from many clients and, depending the scenario, for each request the
server must perform up to 3 DNS queries (NAPTR, SRV and A or AAAA). In
my tests, raising an exception is ~50 times slower than processing a
SIP request by my SIP server, so it would become an easy DoS attack
(in case a attacker sends lots of requests for a non existing domain).




>> 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.

Ok, discarded then :)



>> 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.

But it's not valid in EventMachine and its efficience is really bad. I
must return a value, maybe a Symbol or maybe an instance of a error
class, i.e:

  class EM::Udns::ErrorNoDomain <  EM::Udns::Error ; end
  class EM::Udns::ErrorNoData     <  EM::Udns::Error ; end
  class EM::Udns::ErrorTempFail  <  EM::Udns::Error ; end


Thanks a lot.


-- 
Iñaki Baz Castillo
<ibc@aliax.net>