Problem with rescue clause

[Serenity]

Hello,

I have a strange problem in a haml template where a begin/rescue
clause works properly if I jump into the debugger during it - but not
if I do not.

Here is the code:

- begin
- debugger
= render(:file => @site.custom_template('/menu'), :locals =>
locals)
- rescue
= render(:file => 'templates/menu', :locals => locals)

The template path does not exist, so the rescue is supposed to fire.
As long as the debugger statement is there, then when I hit "continue"
in the debugger, the rescue fires and the other render succeeds.

If I remove the debugger statement, suddenly I just get a blank screen
when hitting the same URL. It is as if this rescue is catching the
exception, but not executing its code.

I'd appreciate any pointers.

[Nathan Weizenbaum]

What version of Haml are you using? Do you see anything on the console log? Does this still fail if you move the begin/rescue to a helper? To ERB?

[Serenity]

I recently installed the latest version of the haml gem. I don't know
if my app picks that up automatically or if I have to do something to
get it to use the new gem. There is no indication in my app that it is
selecting a specific haml version

The problem does not occur when I switch to an erb template. The
rescue clause in the erb template works properly.

It also may be the case that I could easily move this begin/rescue
into a helper as you suggest. That would make for cleaner code so I
will probably do it. But I still want to understand what is going
wrong here b/c this is not the first time I have been bitten by HAML
swallowing up exceptions that it should not have.

[Serenity]

Interestingly, moving the begin/rescue to a helper did not solve the
problem. I now have a very simple/clean haml template:

- cache(path=cache_path('_menu')) do
- prep_menu_render
- wrap_cache(path) do
= menu_render_custom_or_default

and the following helper functions:

def prep_menu_render
@site.parse_url(adjusted_path,flash[:group_label]) unless
@site.parsed
db_item(@site) ? @site.setup_menus :
@site.setup_menus_for_no_exist
@menu_width=get_locals()[:menu_width]
end

def menu_render_custom_or_default
locals = {:menu_width => @menu_width}
begin
render(:file => @site.custom_template('menu'), :locals =>
locals)
rescue #ActionView::TemplateError, ActionView::ActionViewError,
Errno::ENOENT

render(:file => 'templates/menu', :locals => locals)

end
end

and when the template file in the begin clause is missing, I get
nothing back in the browser - empty page.

And again, if I convert the above template to erb, it works properly.

[Nathan Weizenbaum]

To tell the Haml version loaded by your app, use "p Haml.version" in your environment.rb.

You never said if there was any console output.

Could you create a Rails app that's as small as possible but still exhibits this issue, tar it up, and email it to me, so I can reproduce it?

[Serenity]

It says version 2.2.9. Although for what it's worth:

1) I couldn't put that line in my environment.rb, Haml isn't loaded
there.
2) I do have vendor/plugins/haml (which is where I put that p
statement). I don't recall ever doing anything to update this to the
new version of Haml.

What I see in the logs is simply that there is no mention of any haml
processing of the template that raises the exception, or any other
haml file after it.

I will attempt to create a minimum-app that recreates the problem...
will be a bit of work though. In the mean time I look forward to
hearing whether I'm really getting 2.2.9, or if I have some kind of
mixed environment going b/c of the vendor/plugins/haml directory.

[Nathan Weizenbaum]

I had thought that Haml would be loaded at the end of your environment.rb... but I guess not. In any case, if vendor/plugins/haml says that it's 2.2.9, that's probably true. You can also check vendor/plugins/haml/VERSION.

I don't think I'll be able to debug this any further without a solid test case.

2009/10/18 Serenity <dor...@est.org>

[Serenity]

Ok, I have created a minimum app that exhibits the behavior.

The bad news is I had forgotten that this particular rails app is
rails version 1.2.3.

I made versions of the minimum-app for 1.2.6 and 2.0.5. The problem is
gone by 2.0.5, but still exists in 1.2.6.

I'm not sure how many versions of rails there are between these two. I
can understand if you don't want to waste any time identifying an
incompatibility with rails 1.2.6 & earlier.

I'll leave it up to you whether you want me to look into this further.
I'd rather not go install a bunch of rails versions just to zero down
where this changed (though 2.0 seems likely, right?).

I'm happy to send you the 1.2.6 min-app if you do want to figure out
what's wrong here.

[Nathan Weizenbaum]

Technically, we still support Rails 1.2.6, so send the miniapp over and I'll try to figure out what's going on.

Thanks for looking into this so much!

[Avram Dorfman]

How do I send it to you?

Sent from my iPhone

[Nathan Weizenbaum]

Tar it up (or zip if that's easier) and email it to nex...@gmail.com.