From: Pit Capitain <pit@...>
Date: 2005-06-23T15:56:05+09:00
Subject: Re: Super-scalar Optimizations

Steven Jenkins schrieb:
> OK, you got me thinking. I've built a Ruby extension to access a system
> engineering database we use at work. The vendor provides a C API, which
> I've wrapped with SWIG. SWIG is useful, but the generated Ruby methods
> aren't very Ruby-like. So I've written a layer on top of the SWIG
> methods. Most of the layer methods look like this:
> 
>   def framelist
>     ret, list = CAPIitem_getframelist(self)
>     check_result(ret)
>     list
>   end
> 
> Object#check_result is a common method that checks for an error
> indication, finds what the last error was, and raises the corresponding
> exception:
> 
>   def check_result(res)
>     return unless res == Cradle::FALSE
>     code, msg = CAPIlast_error()
>     raise EXCEPTION[code], msg
>   end
> 
> Is there any reason to prefer, or not, using a lambda for check_result?
> The only downside I can see to the current implementation is that the
> backtrace for all exceptions ends in check_result. You have to look at
> the next level to see where the error actually occurred. (I think it's
> almost the same with a lambda, but it doesn't report it's in another
> method).
> 
> Ideas?

If the only goal is to get rid of the topmost entry in the backtrace, 
you don't need a lambda. Just add a third parameter to Kernel#raise. 
Change the last line in check_result to:

   raise EXCEPTION[code], msg, caller

Regards,
Pit