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 Johnston
on 2007-04-01 04:35
on 2007-04-01 04:41
Michael Johnston 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 Wang
on 2007-04-01 04:52
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
on 2007-04-01 05:39
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?
on 2007-04-01 05:45
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
on 2007-04-04 17:47
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
on 2007-04-04 18:30
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
on 2007-04-04 18:44
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.
on 2007-04-05 14:40
Think I finally tracked the problem down. See here : http://groups.google.com/group/rubyonrails-core/br...