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