

Show HN: pry-rescue — workflow-optimized debugging for ruby - cirwin
http://cirw.in/blog/pry-to-the-rescue

======
stcredzero
_> Whenever an unhandled exception happens in your program, pry-rescue opens
an interactive pry shell right at the point it was raised. Instead of
glowering at a stack-trace spewed out by a dying process, you'll be engaging
with your program as though it were still alive!

The pry console gives you access to the method that raised the exception, you
can use it to inspect the values of variables (no more print statements!), the
source code of methods (no more flapping around with a text editor!), and even
move up and down the call stack (like a real debugger!)._

Basically what we were doing in Smalltalk for decades and trying to tell
people about. (To a remarkable degree of push-back and vitriol.) Many years
ago, one of our community pointed out that while it lost out as a mainstream
platform, Smalltalk actually won the war of ideas. (It's taking quite a long
time for everyone else to catch up, however. People keep thinking they've
gotten there when they're still a good 1/3rd short.)

~~~
vidarh
Ruby is pretty much an unholy mix of Perl + Smalltalk + a sprinkling of Lisp
with an extreme syntactic sugar-bomb on top to start with. At least in terms
of inspirations.

And I say that mostly as a compliment (though I still find the Ruby grammar
atrocious from an implementation point of view).

~~~
stcredzero
_> And I say that mostly as a compliment (though I still find the Ruby grammar
atrocious from an implementation point of view)._

I think there is something deep embodied here. Syntactic sugar items for
languages are like features for libraries. It's been said that if everyone is
completely happy with a library's features, the library maintainers haven't
been doing their job.

------
malvim
This is awesome work, thanks!

Just throwing this out there, I know a bit about the difficulties this would
entail, but: Is it plausible to have something like this running in production
mode?

I mean, if I had a production Rack app running and could have pry-rescue
(somehow) save its state and bubble the exception up normally, and later
connect to the process and inspect what went wrong. Would something like this
be feasible?

~~~
cirwin
Yes :). I'm not exactly sure of the details, but I certainly want to try! See
<https://github.com/mrbrdo/rack-webconsole>: there's already a rack-
webconsole-pry, so it should be an easy step to hook it up to past exceptions.

------
picardo
Thanks for this. How would I use it in Rails? Any tips for integration?

~~~
cirwin
In rails you can just do:

    
    
        class ApplicationController < ActionController::Base
          around_filter :pry_rescue if Rails.env == 'development'
    
          def pry_rescue
            Pry::rescue{ yield }
          end
    

I'm hoping to get a Rack middleware out at some point; which will make this
even easier.

~~~
blaines
Here's a basic middleware...

    
    
      pry_rescue.rb
      require 'pry/rescue'
      class PryRescue
        def initialize(app)
          @app = app
        end
    
        def call(env)
          Pry::rescue{ @app.call(env) }
        end
      end
    

For rails you need to require the file and use the middleware...

    
    
      application.rb
      config.middleware.use "PryRescue"

~~~
drewda
I know this is short and simple, but it still might be nice to wrap up in a
gem. Or maybe work into the pry-rails gem?

------
MartinMond
Are there any difference to <https://github.com/pry/pry-exception_explorer> ?

~~~
cirwin
pry-rescue is a modernization thereof (banisterfiend helped me build it).

The only technical difference is that pry-rescue can catch exceptions raised
at the C level (like NoMethodError, or ZeroDivisionError); but pry-rescue also
has a much easier-to-learn API/UI. (Particularly, by only supporting catching
unhandled exceptions, pry-rescue can avoid the need to predicate on which
exceptions should be handled).

------
koenigdavidmj
Why does anyone think that multiple columns for a single story are a good idea
on the web?

~~~
kyrylo
Exclusively for you, my friend :)

Fix for Chrome (Stylebot): <http://goo.gl/9qoeF>

Fix for Firefox (Stylish): <http://goo.gl/6tkpz>

------
cmer
I assume this won't work with Pow as it would require binding.remote_pry?

~~~
cmer
Great job by the way!

------
getriver
Wow, pry and its plugins universe gets better each day.

If you're new to pry I recommend you check pry-remote & pry-debugger.

------
makmanalp
For python, ipython --pdb <derp.py> does the trick. Don't forget to install
ipdb too, much nicer than plain pdb.

~~~
banister
Not sure it's quite the same. My understanding is that `ipython --pdb` would
run the entire program in debugging mode, causing a dramatic slow-down in
performance of the app. The approach taken by pry-rescue in contrast is to
check for exceptions in a bounded portion of code (as many bounded portions as
you want), so the slow-down is constrained to hot spots. This potentially
makes pry-rescue OK for production use, something perhaps not suitable for
ipython --pdb afaict.

~~~
gingerlime
you're probably right, and it sounds like a nice idea to create an exception
wrapper that on exception does `import ipdb; ipdb.set_trace()`.

However, having worked with both pry and ipython / ipdb, the difference in
responsiveness and performance is quite significant and very noticeable
between the two. ipython / ipdb feels faster by an order of magnitude. The
most obvious difference is tab-completion. Perhaps this is enhanced even more
comparing rails to django (the stacks I used pry and ipdb with,
respectively)...

I guess at least tab-completion slowness is down to the fact that by its
nature ruby has far many more functions that can run on any object than
python, and hence more options to tab-complete?

~~~
banister
hmm, weird. Aside from tab-completion what else is slow? I've never had
responsiveness issues with Pry, even tab completion is snappy.

~~~
gingerlime
I actually think it's mostly rails, not pry. I'm still new to rails and ruby,
but somehow it feels much slower than django. Just loading the console feels
like forever compared to the django shell.

However, regarding tab completion. I just did a quick test and noticed a small
but important difference. Clicking tab in ipython instantly shows you the
available completions. in pry, most of the time I have to click _twice_ to see
them! maybe that's what makes it feel slow to me.

~~~
banister
Possibly :) tab-completion will be substantially improved in an upcoming
release :)

~~~
gingerlime
Great! looking forward to it. :)

------
meedimusic
is there any way to make this compatible with ruby 1.8.7? Seems like just what
I need, but haven't upgraded my current app with a newer version of ruby.

~~~
cirwin
It is :). The "up" and "down" command won't work, and there are a few bugs
with NoMethodError's, but the core functionality is very much there.

------
teffen
This is really cool. Looking forward to a rails version of the gem!

