Hi,
in my feedreader I found a link to interesting gem - better_errors (https://github.com/charliesome/better_errors).
It makes rails (and not only rails) error page in development env more usable than before. It makes stacktrace clickable and for each line in stacktrace it displays source code around that line, list of local and instance variables with values and interactive REPL inside that error page.
Hope it will make development of ruby/rails apps easier.
-- Petr Blaho, pblaho@redhat.com Software Engineer, CloudForms
On 12/10/2012 09:51 AM, Petr Blaho wrote:
Hi,
in my feedreader I found a link to interesting gem - better_errors (https://github.com/charliesome/better_errors).
It makes rails (and not only rails) error page in development env more usable than before. It makes stacktrace clickable and for each line in stacktrace it displays source code around that line, list of local and instance variables with values and interactive REPL inside that error page.
Hope it will make development of ruby/rails apps easier.
Yeah I looked at that as well and I'm definitely in favour of giving this a try.
What Sayeth The Community?
-- Petr Blaho, pblaho@redhat.com Software Engineer, CloudForms
On Tue, Dec 11, 2012 at 01:59:56PM +0100, Tomas Sedovic wrote:
On 12/10/2012 09:51 AM, Petr Blaho wrote:
Hi,
in my feedreader I found a link to interesting gem - better_errors (https://github.com/charliesome/better_errors).
It makes rails (and not only rails) error page in development env more usable than before. It makes stacktrace clickable and for each line in stacktrace it displays source code around that line, list of local and instance variables with values and interactive REPL inside that error page.
Hope it will make development of ruby/rails apps easier.
Yeah I looked at that as well and I'm definitely in favour of giving this a try.
What Sayeth The Community?
It's really slick, and definitely _much_ better than what's included by default.
It seems to be of limited use in Conductor, though, because we rescue nearly all exceptions in ApplicationController and display a flash message, so errors never bubble up high enough for better_errors to handle them.
I did comment them out in application_controller.rb to play around, though, and I'm really liking it. I briefly thought that we could try to conditionalize these based on environment, but I think that's a bad idea. (It seems that "only in development" or "only in production" patches have _always_ blown up in my face.)
I suppose that when debugging unexpected errors, it wouldn't be a bad idea to comment the rescue lines out, and then drop 'better_errors' and 'binding_of_caller' (for the interactive REPL) in your Gemfile? :-\
-- Matt
----- Original Message -----
From: "Matt Wagner" matt.wagner@redhat.com To: "Tomas Sedovic" tsedovic@redhat.com Cc: aeolus-devel@lists.fedorahosted.org Sent: Tuesday, December 11, 2012 4:55:10 PM Subject: Re: [TIP] better_errors gem
On Tue, Dec 11, 2012 at 01:59:56PM +0100, Tomas Sedovic wrote:
On 12/10/2012 09:51 AM, Petr Blaho wrote:
Hi,
in my feedreader I found a link to interesting gem - better_errors (https://github.com/charliesome/better_errors).
It makes rails (and not only rails) error page in development env more usable than before. It makes stacktrace clickable and for each line in stacktrace it displays source code around that line, list of local and instance variables with values and interactive REPL inside that error page.
Hope it will make development of ruby/rails apps easier.
Yeah I looked at that as well and I'm definitely in favour of giving this a try.
What Sayeth The Community?
It's really slick, and definitely _much_ better than what's included by default.
It seems to be of limited use in Conductor, though, because we rescue nearly all exceptions in ApplicationController and display a flash message, so errors never bubble up high enough for better_errors to handle them.
I did comment them out in application_controller.rb to play around, though, and I'm really liking it. I briefly thought that we could try to conditionalize these based on environment, but I think that's a bad idea. (It seems that "only in development" or "only in production" patches have _always_ blown up in my face.)
Hmm... Seems like that wouldn't have to be a separate patch, but maybe just an environment specific configuration value. To be fair, I haven't looked at the code at all, but seems like you could have a conditional based on a config value that's environment specific.
Just a thought.
I suppose that when debugging unexpected errors, it wouldn't be a bad idea to comment the rescue lines out, and then drop 'better_errors' and 'binding_of_caller' (for the interactive REPL) in your Gemfile? :-\
-- Matt
On 12/12/12 08:35 -0500, Greg Blomquist wrote:
----- Original Message -----
From: "Matt Wagner" matt.wagner@redhat.com To: "Tomas Sedovic" tsedovic@redhat.com Cc: aeolus-devel@lists.fedorahosted.org Sent: Tuesday, December 11, 2012 4:55:10 PM Subject: Re: [TIP] better_errors gem
On Tue, Dec 11, 2012 at 01:59:56PM +0100, Tomas Sedovic wrote:
On 12/10/2012 09:51 AM, Petr Blaho wrote:
Hi,
in my feedreader I found a link to interesting gem - better_errors (https://github.com/charliesome/better_errors).
It makes rails (and not only rails) error page in development env more usable than before. It makes stacktrace clickable and for each line in stacktrace it displays source code around that line, list of local and instance variables with values and interactive REPL inside that error page.
Hope it will make development of ruby/rails apps easier.
Yeah I looked at that as well and I'm definitely in favour of giving this a try.
What Sayeth The Community?
It's really slick, and definitely _much_ better than what's included by default.
It seems to be of limited use in Conductor, though, because we rescue nearly all exceptions in ApplicationController and display a flash message, so errors never bubble up high enough for better_errors to handle them.
I did comment them out in application_controller.rb to play around, though, and I'm really liking it. I briefly thought that we could try to conditionalize these based on environment, but I think that's a bad idea. (It seems that "only in development" or "only in production" patches have _always_ blown up in my face.)
Hmm... Seems like that wouldn't have to be a separate patch, but maybe just an environment specific configuration value. To be fair, I haven't looked at the code at all, but seems like you could have a conditional based on a config value that's environment specific.
Just a thought.
Yeah, that is absolutely how you'd want to add the gem dependencies (as shown in the readme[1]). However, since conductor catches a digests all errors in the application controller, that block would probably also need to be conditionalized. On a quick look at the code, it appears you could just wrap all the rescue_froms in an env check, something like if(['RAILS_ENV'].eql?('production')) or similar. Just a thought, but this could even end up handy for debugging production setups. We often help people debug by telling them to restart the app in dev mode to get better error logging, so this would allow them to get not only that, but have an easy way to view them. Either way, I don't really see a downside here if people like it.
-j
[1] https://github.com/charliesome/better_errors#installation
----- Original Message -----
From: "Jason Guiditta" jguiditt@redhat.com To: "Greg Blomquist" gblomqui@redhat.com Cc: aeolus-devel@lists.fedorahosted.org, "Tomas Sedovic" tsedovic@redhat.com, "Matt Wagner" matt.wagner@redhat.com Sent: Friday, December 14, 2012 9:26:20 AM Subject: Re: [TIP] better_errors gem
On 12/12/12 08:35 -0500, Greg Blomquist wrote:
----- Original Message -----
From: "Matt Wagner" matt.wagner@redhat.com To: "Tomas Sedovic" tsedovic@redhat.com Cc: aeolus-devel@lists.fedorahosted.org Sent: Tuesday, December 11, 2012 4:55:10 PM Subject: Re: [TIP] better_errors gem
On Tue, Dec 11, 2012 at 01:59:56PM +0100, Tomas Sedovic wrote:
On 12/10/2012 09:51 AM, Petr Blaho wrote:
Hi,
in my feedreader I found a link to interesting gem - better_errors (https://github.com/charliesome/better_errors).
It makes rails (and not only rails) error page in development env more usable than before. It makes stacktrace clickable and for each line in stacktrace it displays source code around that line, list of local and instance variables with values and interactive REPL inside that error page.
Hope it will make development of ruby/rails apps easier.
Yeah I looked at that as well and I'm definitely in favour of giving this a try.
What Sayeth The Community?
It's really slick, and definitely _much_ better than what's included by default.
It seems to be of limited use in Conductor, though, because we rescue nearly all exceptions in ApplicationController and display a flash message, so errors never bubble up high enough for better_errors to handle them.
I did comment them out in application_controller.rb to play around, though, and I'm really liking it. I briefly thought that we could try to conditionalize these based on environment, but I think that's a bad idea. (It seems that "only in development" or "only in production" patches have _always_ blown up in my face.)
Hmm... Seems like that wouldn't have to be a separate patch, but maybe just an environment specific configuration value. To be fair, I haven't looked at the code at all, but seems like you could have a conditional based on a config value that's environment specific.
Just a thought.
Yeah, that is absolutely how you'd want to add the gem dependencies (as shown in the readme[1]). However, since conductor catches a digests all errors in the application controller, that block would probably also need to be conditionalized. On a quick look at the code, it appears you could just wrap all the rescue_froms in an env check, something like if(['RAILS_ENV'].eql?('production')) or similar. Just a thought, but this could even end up handy for debugging production setups. We often help people debug by telling them to restart the app in dev mode to get better error logging, so this would allow them to get not only that, but have an easy way to view them. Either way, I don't really see a downside here if people like it.
Heh, reminds me of the old Java days:
if (log.isDebugEnabled()) { log.debug("something") }
Alright Jay, for your next trick, please make the nightmares stop!
-j
[1] https://github.com/charliesome/better_errors#installation
On Fri, Dec 14, 2012 at 09:26:20AM -0500, Jason Guiditta wrote:
On 12/12/12 08:35 -0500, Greg Blomquist wrote:
----- Original Message -----
From: "Matt Wagner" matt.wagner@redhat.com To: "Tomas Sedovic" tsedovic@redhat.com Cc: aeolus-devel@lists.fedorahosted.org Sent: Tuesday, December 11, 2012 4:55:10 PM Subject: Re: [TIP] better_errors gem
On Tue, Dec 11, 2012 at 01:59:56PM +0100, Tomas Sedovic wrote:
On 12/10/2012 09:51 AM, Petr Blaho wrote:
Hi,
in my feedreader I found a link to interesting gem - better_errors (https://github.com/charliesome/better_errors).
It makes rails (and not only rails) error page in development env more usable than before. It makes stacktrace clickable and for each line in stacktrace it displays source code around that line, list of local and instance variables with values and interactive REPL inside that error page.
Hope it will make development of ruby/rails apps easier.
Yeah I looked at that as well and I'm definitely in favour of giving this a try.
What Sayeth The Community?
It's really slick, and definitely _much_ better than what's included by default.
It seems to be of limited use in Conductor, though, because we rescue nearly all exceptions in ApplicationController and display a flash message, so errors never bubble up high enough for better_errors to handle them.
I did comment them out in application_controller.rb to play around, though, and I'm really liking it. I briefly thought that we could try to conditionalize these based on environment, but I think that's a bad idea. (It seems that "only in development" or "only in production" patches have _always_ blown up in my face.)
Hmm... Seems like that wouldn't have to be a separate patch, but maybe just an environment specific configuration value. To be fair, I haven't looked at the code at all, but seems like you could have a conditional based on a config value that's environment specific.
Just a thought.
Yeah, that is absolutely how you'd want to add the gem dependencies (as shown in the readme[1]). However, since conductor catches a digests all errors in the application controller, that block would probably also need to be conditionalized. On a quick look at the code, it appears you could just wrap all the rescue_froms in an env check, something like if(['RAILS_ENV'].eql?('production')) or similar.
I do not like idea of depending on RAILS_ENV variable here. Even if we will use unless and test for development env we need proper exceptions handling (as is written right now) in tests and when developing API we need them in development env too to return proper response.
Just a thought, but this could even end up handy for debugging production setups. We often help people debug by telling them to restart the app in dev mode to get better error logging, so this would allow them to get not only that, but have an easy way to view them. Either way, I don't really see a downside here if people like it.
-j
[1] https://github.com/charliesome/better_errors#installation
Of course I am glad this thread lives b/c I would like to see more dev tools in basic conductor setup.
Thanks
-- Petr Blaho, pblaho@redhat.com Software Engineer, CloudForms
aeolus-devel@lists.fedorahosted.org
-
Greg Blomquist -
Jason Guiditta -
Matt Wagner -
Petr Blaho -
Tomas Sedovic