From: Christopher Dicely Date: 2011-05-02T05:48:47+09:00 Subject: Re: Is it usual/valid to extend custom classes under Errno module? On Sun, May 1, 2011 at 5:22 AM, Iñaki Baz Castillo wrote: > 2011/5/1 Christopher Dicely : >> On Fri, Apr 22, 2011 at 11:15 AM, Iñaki Baz Castillo 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. That's not surprising. Still, unless its really not an exceptional case, an exception is usually better in library code. > 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. If you are writing an asynchronous, non-blocking DNS library on top of EventMachine, and returning results the same way you get them back (via callbacks), then, yeah, raising an exception is just going to cause all kinds of problems. You could probably return (not raise) an exception (have a separate Exception class for each broad type of errors, and populated it with the appropriate details; this seems to be approximately what your Errno based approach would do -- Errno, after all, is a descendant of Exception) in your error callbacks. OTOH, if you aren't going to be providing any additional information other than the general type of error, either a symbol or an opaque constant defined in your library works just as well.