On Oct 25, 8:41 am, "Michael Koziarski" <[EMAIL PROTECTED]> wrote: > > > 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: > > I think a patch which preserves (grants) the ability to use strings as > arguments to rescue_from but fixes the semantics would be good to > review.
Here we go! http://dev.rubyonrails.org/ticket/10079 The diff has been computed from edge a few minutes ago. I chose to provide rescue priority from right to left, bottom to top, and up the hierarchy. Since the code that raises exceptions appears usually below the declarations, and I would expect handlers in children to be called before handlers in parents, I thought that could be an intuitive order. As per strings, since the objective was to be able to declare handlers for exceptions whose definition has not yet been seen, when we loop over the handlers when an exception is raised we do not complain if some string-to-constant fails. Perhaps that's an early exception and we have not yet seen the definition, so a NameError didn't seem consistent with the original aim. Another objective was to be able to declare handlers for classes that won't be loaded at all, we accomplish that as well. Typos won't be apparent unfortunately, but we can't be strict and tolerant at the same time. Best, -- 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 -~----------~----~----~----~------~----~------~--~---
