/__better_errors does not work if there was no error #54

Closed
SeriousM opened this Issue Dec 13, 2012 · 3 comments

Comments

Projects
None yet
3 participants
@SeriousM

Hi, first of all: GREAT WORK MAN!!!

when i request the page /__better_errors it shows the generic error page instead better_errors one. if i force an error the page works as it should.

NoMethodError (undefined method `render' for nil:NilClass):
  better_errors (0.2.0) lib/better_errors/middleware.rb:31:in `show_error_page'
  better_errors (0.2.0) lib/better_errors/middleware.rb:15:in `call'

4 things:
1: can we get the REPL at any time or is an exception needed
2: under which circumstances i can have the REPL in the production
3: under which circumstances i can have the better_errors page in the production
4: can i protect the page somehow?

thanks for this great work!

@rstacruz rstacruz closed this in 43951f8 Dec 13, 2012

@rstacruz

This comment has been minimized.

Show comment Hide comment
@rstacruz

rstacruz Dec 13, 2012

Collaborator

Thanks! Here you go: not exactly an ideal solution, but we can always revisit the design for this page later.

image

Collaborator

rstacruz commented Dec 13, 2012

Thanks! Here you go: not exactly an ideal solution, but we can always revisit the design for this page later.

image

@rstacruz

This comment has been minimized.

Show comment Hide comment
@rstacruz

rstacruz Dec 13, 2012

Collaborator

Answers:

1: can we get the REPL at any time or is an exception needed

Yes, you need an exception for a REPL. A shell is ran in the context of an error's backtrace. I don't think @charliesome has plans for a standalone REPL yet.

2: under which circumstances i can have the REPL in the production

You can't have a REPL in production. By design, the better_errors gem will refuse to load in a production environment.

3: under which circumstances i can have the better_errors page in the production

Same answer as 2.

4: can i protect the page somehow?

See #36.

I urge you to reconsider finding a solution to getting a REPL shell in a production environment... that seems like a bad idea. Instead, I suggest integrating it into your deploy process: there are ways to integrate a cap rails:console command to Capistrano (see this), or if you're using Mina, there's the built-in mina console command.

An in-browser REPL console (independent of an associated error) seems like a cool idea though.

Collaborator

rstacruz commented Dec 13, 2012

Answers:

1: can we get the REPL at any time or is an exception needed

Yes, you need an exception for a REPL. A shell is ran in the context of an error's backtrace. I don't think @charliesome has plans for a standalone REPL yet.

2: under which circumstances i can have the REPL in the production

You can't have a REPL in production. By design, the better_errors gem will refuse to load in a production environment.

3: under which circumstances i can have the better_errors page in the production

Same answer as 2.

4: can i protect the page somehow?

See #36.

I urge you to reconsider finding a solution to getting a REPL shell in a production environment... that seems like a bad idea. Instead, I suggest integrating it into your deploy process: there are ways to integrate a cap rails:console command to Capistrano (see this), or if you're using Mina, there's the built-in mina console command.

An in-browser REPL console (independent of an associated error) seems like a cool idea though.

shime added a commit to shime/better_errors that referenced this issue Dec 14, 2012

@epitron

This comment has been minimized.

Show comment Hide comment
@epitron

epitron Dec 19, 2012

Being able to instantly access your app's console (without having to boot up the entire Rails stack) does actually sound like a compelling feature. (Especially if better_errors starts coming up with pretty ways of representing Ruby objects in HTML.)

I think this is another feature that should be optional.

epitron commented Dec 19, 2012

Being able to instantly access your app's console (without having to boot up the entire Rails stack) does actually sound like a compelling feature. (Especially if better_errors starts coming up with pretty ways of representing Ruby objects in HTML.)

I think this is another feature that should be optional.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment