On Oct 23, 8:41 pm, "Jeremy Kemper" <[EMAIL PROTECTED]> wrote:
> On 10/23/07, fxn <[EMAIL PROTECTED]> wrote:
>
> > rescue_from stores exception class names in a hash table, and
> > associates them with handlers.
>
> > When an exception is raised there's a name lookup, and if an entry is
> > found its handler is invoked. In particular rescue_from does not
> > emulate Ruby's rescue semantics with regard to inheritance.
>
> > Which is the rationale? Don't you think taking is_a? and declaration
> > order into account would provide a better (expected) usage? I could
> > write a patch in that case.
>
> So you can declare handlers before exception classes or for classes
> which may be unavailable (say, you have Active Record disabled.)
Thank you, I don't get it though.
An invocation requires classes as arguments:
def rescue_from(*klasses, &block)
...
klasses.each do |klass|
rescue_handlers[klass.name] = options[:with]
end
end
so they have to be defined at the point of the declaration. Taking
that into account, why handler_for_rescue does this:
def handler_for_rescue(exception)
case handler = rescue_handlers[exception.class.name]
when Symbol
method(handler)
when Proc
handler.bind(self)
end
end
instead of this (off the top of my head):
def handler_for_rescue(exception)
pair = rescue_handlers.select do |pair|
exception.is_a?(pair.exception)
end
return unless pair
case pair.handler
when Symbol
method(pair.handler)
when Proc
pair.handler.bind(self)
end
end
assuming request_handlers in this alternative is an array of pairs of
some sort to preserve declaration order.
-- fxn
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---
