Hi,
I must be missing something or have something misconfigured, but I
get no stack-trace when there is an error in the code behind a view.
If the view doesn’t compile, then I see an error & stacktrace, but
all other errors I get a “lost network connection” from the browser,
and nothing at all in the server output or development.log.
It’s been that way with this app I’m working on for as long as I can
remember. Sometimes I wrap the whole view in a begin/rescue block to
find out what’s going on, but now the annoyance level has reached the
point where I’m posting about it 
I have no idea why this happens, or what I could have done to make it
start happening, or even where to start to figure out what’s going on
with it.
Anyone else have/fix/understand this problem?
Cheers,
Michael J.
Thanks, I do have whiny_nils set to true, so it’s not that.
And it is any error at all except for view compile errors.
I don’t remember if error reporting was ever working – it took me a
while to figure out that not getting stacktraces was not normal :).
Michael
Michael J. wrote:
remember. Sometimes I wrap the whole view in a begin/rescue block to
find out what’s going on, but now the annoyance level has reached the
point where I’m posting about it 
I have no idea why this happens, or what I could have done to make it
start happening, or even where to start to figure out what’s going on
with it.
Anyone else have/fix/understand this problem?
Are these nil errors or something else? There’s a setting in your
config/environments/ files called “config.whiny_nils”. If you’ve set
that to false it won’t log nil errors.
–
Michael W.
Ok, I got this far:
in rescue.rb,
def perform_action_with_rescue #:nodoc:
perform_action_without_rescue
RAILS_DEFAULT_LOGGER.debug("rescue.rb - A: ")
rescue Exception => exception # errors from action performed
RAILS_DEFAULT_LOGGER.debug("rescue.rb - B: ")
it never gets to either point 127 or line 129
so something is de-railing the exception handling
because of all the method-aliasing, it is difficult to decipher the
stacktrace and find out what is going on. I’ll try to go deeper later.
In the meantime, does anyone have an idea what would be keeping the
exceptions from bubbling back to perform_action_with_rescue?
Sorry, this should read:
in rescue.rb,
def perform_action_with_rescue #:nodoc:
perform_action_without_rescue
RAILS_DEFAULT_LOGGER.debug("rescue.rb - A: ")
rescue Exception => exception # errors from action performed
RAILS_DEFAULT_LOGGER.debug("rescue.rb - B: ")
it never gets to either point A or line B
I had this exact same problem and I only managed to find information
that suggested that this so-called White Screen of Death (WSOD) was
due to problems with sessions. As I had recently moved to using
SQLSessionStore, I thought this was to blame but in fact it was a mere
coincidence and my problem was with using views named in the latest
Edge Rails format of action.format.erb (e.g. show.html.erb). Once I
switched to using action.erb, everything was fine again.
You mentioned that you’ve had this problem for a while however and I
believe the naming scheme I mention is recent so I doubt it is to
blame, however I thought it was worth mentioning.
The only other advice I’ve seen is to run rake db:sessions:clear (if
you are using database sessions) or rake tmp:sessions:clear if you
are using the default file-system-based sessions.
– Paul
Thanks for the tips.
I’ll experiment with some this and see what happens. Did you see my
reply where I mentioned that I discovered that the problem was
related to Globalize? Maybe globalize is doing something that
triggers one of these issues.
Cheers,
Michael
I’ve been seeing this problem for a while - at least as far back as
1.1, I think. I don’t have Globalize installed.
