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(a)redhat.com Software Engineer, CloudForms

From: "Matt Wagner" <matt.wagner(a)redhat.com&gt; To: "Tomas Sedovic" <tsedovic(a)redhat.com&gt; Cc: aeolus-devel(a)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.)

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

From: "Jason Guiditta" <jguiditt(a)redhat.com&gt; To: "Greg Blomquist" <gblomqui(a)redhat.com&gt; Cc: aeolus-devel(a)lists.fedorahosted.org, "Tomas Sedovic" <tsedovic(a)redhat.com&gt;, "Matt Wagner" <matt.wagner(a)redhat.com&gt; 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(a)redhat.com&gt; >> To: "Tomas Sedovic" <tsedovic(a)redhat.com&gt; >> Cc: aeolus-devel(a)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