We're sorry, but something went wrong.

start your server with script/server --debugger or script/server -u (this is the same)

then set a breakpoint in this method like

def find_cart    debugger    session[:cart] ||= Cart.new end

then you can look, what is exactly in your session var the development.log output of the console changes into irb mode where you have access to all current given / set vars.

be careful, WHERE you are. If you are in the controller and have a before_filter, you won't have access yet to all variables, so you'd have to look for an already set cart in your DB

greez

Rafael Schaer { beYou media } wrote:

start your server with script/server --debugger or script/server -u (this is the same)

then set a breakpoint in this method like

def find_cart    debugger    session[:cart] ||= Cart.new end

then you can look, what is exactly in your session var the development.log output of the console changes into irb mode where you have access to all current given / set vars.

be careful, WHERE you are. If you are in the controller and have a before_filter, you won't have access yet to all variables, so you'd have to look for an already set cart in your DB

greez

Hi,

Thanks for the response. While you were posting, I searched on google for that rails error message. I read a post where someone posted their development.log, so I poked around in my development.log, and I found this:

  Status: 500 Internal Server Error   can't dump hash with default proc

I took that to mean that I was trying to store an object in a session that I shouldn't be. So I started flipping through the back half of AWDWR(3rd), and in a section titled Cookies and Sessions/Rails Sessions(p. 473) the book says,

    Unlike raw cookies, sessions can hold any objects(as long as those objects can be     marshaled), ... marshal -> page 678

On p. 678 it says,

   If the objects to be dumped ["marshaled"] include bindings, procedure ["proc"] or method objects, ...    a TypeError will be raised.

This is my initialize() method in the Cart class(which is called by Cart.new):

class Cart   attr_reader :items

  def initialize     @items = Hash.new do |hash, key|       hash[key] = 0     end   end

So I guess assigning a Cart object to a session doesn't work because a Cart object has an internal object which is a Hash and that has a proc object associated with it??

I changed my code to use an array (like the book does), and I don't get that error message anymore.

I tried your 'debug' suggestion, but this is what happened:

/depot$ ruby script/server -u => Booting Mongrel => Rails 2.3.2 application starting on http://0.0.0.0:3000 You need to install ruby-debug to run the server in debugging mode. With gems, use 'gem install ruby-debug'

So I'll have to install that gem.

I'm just wondering why rails doesn't display the TypeError along with a stack trace?

On p. 678 it says,

If the objects to be dumped ["marshaled"] include bindings, procedure ["proc"] or method objects, ... a TypeError will be raised.

This is my initialize() method in the Cart class(which is called by Cart.new):

class Cart attr_reader :items

def initialize @items = Hash.new do |hash, key| hash[key] = 0 end end

So I guess assigning a Cart object to a session doesn't work because a Cart object has an internal object which is a Hash and that has a proc object associated with it??

A hash with a default value that is a proc has (you guessed it) a proc embedded in it. There are a few places in rails where if things go badly wrong at a time rails didn't expect it you just get a 'sorry it's screwed' error rather than the usual informative error message, session creation can be one of them.

Fred

7stud -- wrote:

Is the error saying Product isn't hashable?

I think that had to do with an old version of the cart implemented with an array that was still stored in sessions. I cleared my sessions with:

rake db:sessions:clear

and that got rid of the error.

It should. How are you running your app? If you run it with script/server, unless you're forcing production mode, you should get a nice error page with a stack trace, error information, session dump, etc.

--Jeremy

Jeremy McAnally wrote:

It should.

Sorry, I'm not sure what that is referring to.

How are you running your app? If you run it with script/server, unless you're forcing production mode, you should get a nice error page with a stack trace, error information, session dump, etc.

--Jeremy

All standard stuff:

sqlite3 development ruby script/server --> Mongrel

However, I just changed my code back to what I posted, then cleared the sessions with:

rake db:sessions:clear

and now using a Product object as a key in the hash works fine.

I think all the massive problems I've had with sessions definitely highlights this point in my book:

One thing that you may or may not know is that the default session storage for Rails is cookies now. Therefore, if you have any unexpected failures and subsequent bizarre behaviour in your application, first thing to do is to clear cookies, otherwise you will be chasing either wrong problems or non-existent problems. This is not specific to rails but to any system that uses cookies for session storage. Bharat