We're sorry, but something went wrong

Rails
1

Great. I’m in the development environment and that is the error message
I get?! What good does that do me?

I’m trying to follow along with the examples in AWDWR(3rd.), and I have
this method in a store controller:

private
def find_cart
Cart.new
end

That works fine, except that every request(initiated by clicking on an
‘add to cart’ button) will cause a new cart to be created, so only the
currently selected item will be shown in the cart. Sessions to the
rescue! But when I change that method to:

private
def find_cart
sessions[:cart] ||= Cart.new
end

I get the very uninformative error:

We’re sorry, but something went wrong.
We’ve been notified about this issue and we’ll take
a look at it shortly.

I’ve tried rolling back my migrations so that all the tables are deleted
and then recreating them. I’ve tried:

rake db:sessions:clear

but nothing gets rid of that error. I’ve restarted my server about
40,000 times, so that isn’t the problem.

I hate frameworks.

rails 2.3.2

2

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

3

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.

4

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

5

attr_reader :items

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

6

Frederick C. wrote:

� attr_reader :items

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

I’m having problems with this stupid thing again. In ruby, I can use
any object as a key for a hash:

class A
end
a = A.new

h = Hash.new
h[a] = 5

if h[a]
h[a] += 1
end

p h

–output:–
{#<A:0x2524c>=>6}

But if I try the same thing in rails using a Product object as the key(I
have Product model linked to a products table), I get an error:

TypeError in StoreController#add_to_cart

can’t convert Product into Integer

RAILS_ROOT: /Users/me/2testing/dir1/rails/test
Application Trace | Framework Trace | Full Trace

/Users/me/2testing/dir1/rails/test/app/models/cart.rb:9:in []' /Users/me/2testing/dir1/rails/test/app/models/cart.rb:9:inadd_item’
/Users/me/2testing/dir1/rails/test/app/controllers/store_controller.rb:9:in
`add_to_cart’

class StoreController < ApplicationController
def index
@products = Product.get_products_for_sale
end

def add_to_cart <—***clicking on a button calls this action
product = Product.find(params[:id])
@cart = get_cart
@cart.add_item(product) #<–****calls method in Cart class
end

private
def get_cart
session[:cart] ||= Cart.new
end

end

#cart.rb:

class Cart
attr_reader :items

def initialize
@items = {}
end

def add_item(product)

if @items[product]    <-----*** line 9 ERROR
  @items[product] += 1
else
  @items[product] = 1
end

end
end

Is the error saying Product isn’t hashable?

7

7stud – wrote:

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.

Actually, that didn’t get rid of the error. I still get the same error.

8

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.

9

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

On Fri, Apr 24, 2009 at 2:17 AM, 7stud –
[email protected] wrote:

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

Posted via http://www.ruby-forum.com/.

–
http://jeremymcanally.com/
http://entp.com/

My books:

http://humblelittlerubybook.com/ (FREE!)

10

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

11

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:

…it’s generally a really bad idea to store application-level objects
in session data.
…
Instead, the recommended practice is to store only simple data in the
session: strings, numbers, and so on. Keep your application objects in
the database, and then reference them using their primary keys from the
session data.

AWDWR(3rd) p. 106

I think the problem with storing objects in sessions is that any little
change you make to your code requires that you clear all the session
data (and restart the server) because now a previously stored object is
not consisted with your new code.

Following those guidelines, my Cart class would look like this:

class Cart
attr_reader :items

def initialize
@items = {}
end

def add_item(product)
if @items[product.id]
@items[product.id] += 1
else
@items[product.id] = 1
end
end
end

and that works too.

12

Bharat R. wrote:

One thing that you may or may not know is that the default session
storage for Rails is cookies now.

I followed some instructions to uncomment one line in
config/initializers/session_store.rb (rails 2.3), which created database
storage for sessions, hence the repeated use of:

db:sessions:clear

That’s certainly an important point that I did not remember to post.