Hacker News Reader

Comment by mysterydip | Hacker News Reader

The problem with breakpoints is my loop runs 1000 times and I only care about the one time it errors. Making watch logic for that sometimes is too complicated or changes the outcome (race conditions especially). This seems like a great solution. I'll be checking it out!

View on HN

If you can trigger a debugger from a keyword it's usually pretty easy to trigger it conditionally or on an exception in the code rather than through a GUI.

That works well for ruby and javascript and probably lots of others.

e.g. something like the equivalent of

  def foo
    bar.map do |b|
     b.do_something!
     debugger if b.state == :something_youre_interested_in
    end
  rescue => e
   debugger
  end

I'm really excited by Replay. I think it will be invaluable.

Yes, but I think this is what they meant by

> Making watch logic for that sometimes is too complicated or changes the outcome (race conditions especially).

Why is that better than using your IDE? Your writing debugging code directly in you production code...

How would you debug something inside of a loop (1000s of values) with a line breakpoint in your IDE? Your debugger will trigger the breakpoint every single time it walks through the loop, even when everything is going fine. Now if you conditionally trigger the breakpoint inside the loop using code, it will trigger once and only if it encounters whatever error you want to catch.

Obviously you remove that debug statement from your code after you're finished debugging.

Browsers have conditional breakpoints available in their tools/debuggers so you can write them without changing the code.

I haven't personally used Replay, but from my experience using rr (a native debugger that also provides time-traveling features) being able to replay execution both backwards and forwards in time on a whim is amazing. These tools excel at diagnosing bugs that are hard to reproduce, because you only have to reproduce the bug once under the debugger and then you can endlessly replay that execution until you figure it out. As Jason said above, you can retroactively add print statements in places that would be useful, without having to waste time trying to reproduce the bug again!

roc (the original author of rr) founded a company to build an even more compelling product on top of rr called Pernosco. They have some mind-blowing demos I'd recommend you check out: https://pernos.co/ .

Being able to easily answer questions like "where did the value in this variable come from, and when did it get set?" makes debugging a wildly different experience.

Err, conditional breakpoints are your friend.

Also the GP claims "nobody" uses breakpoints? Everyone in my team uses them all the time.

Suppose it all depends on your language/tool chain, in my experience breakpoints are very commonly used by developers in visual studio.

I assume he referred to breakpoints in the browser.

Chrome does conditional breakpoints - just edit the breakpoint and type your condition in - but it massively slows down the page of that code gets hit a lot.

So much so that I prefer to put the condition in my local build as source code then put a normal breakpoint on that after it has rebuilt (a few millseconds with a good watcher)

I use it ALL the time. Not sure how people are debugging code nowadays?

Which debugger do you use because I live in JetBrains tools and their debugger front-end support for conditional or on exception break points is phenomenal

The debugger in devtools also has these capabilities.

Can confirm. Use it often both on Chrome and Firefox.

I love the idea of reply, but is it targeting the wrong people to get the post leverage out of it? Print statements generally don't need to be used for debugging if you know how to use a debugger. Which really isn't difficult if you spend maybe half an hour learning it's features.

What I mean is coming up with a condition to make as a watch/breakpoint isn't always obvious. Especially with errors that happen "sometimes randomly".

That’s exactly where replay should shine. Stick a breakpoint in your error handler, then rewind when it breaks.

Actually it might be even easier — if your specific error shows up in the console, there's a handy rewind button right beside it :)

If an error causes an exception there is an option to suspend execution when one is thrown.

But typically it will throw an exception _after_ the interesting code happened. For instance it might throw a NullPointerException, but you want to know what set it to null in the first place. With breakpoints you have to suspend on exception, and then add additional breakpoints earlier in the code, and then rerun the code. With rewind you can just step backwards.

For Python, but only if execution is deterministic, I made a small library that tries to address that issue: https://github.com/breuleux/breakword (it prints data alongside a deterministic list of words and you can set a breakpoint on a word of interest in a second run).

It's really a poor man's replay, though. That tool looks really slick, I'll definitely give the Python version a go if/when it comes!

Err, conditional breakpoints are your friend.

Also, "nobody" uses breakpoints? Everyone in my team uses them all the time.

Perhaps the comment was a generalization and not a attack on your process. Its not a radical claim to suggest breakpoints are not as popular as console.logs

Reply on news.ycombinator.com