8 ms·
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 o
by mysterydip 5y ago
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!
- rubyist5eva 5y agoWhich 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
- bentlegen 5y agoThe debugger in devtools also has these capabilities.
- spicybright 5y agoCan 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.
- mysterydip 5y agoWhat 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".
- onionisafruit 5y agoThat’s exactly where replay should shine. Stick a breakpoint in your error handler, then rewind when it breaks.
- jaril 5y agoActually it might be even easier — if your specific error shows up in the console, there's a handy rewind button right beside it :)
- rubyist5eva 5y agoIf an error causes an exception there is an option to suspend execution when one is thrown.
- zerd 5y agoBut 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.
- Lio 5y agoIf 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.
- lovegoblin 5y agoYes, 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).
- HeavyStorm 5y agoWhy is that better than using your IDE? Your writing debugging code directly in you production code...
- sprremix 5y agoHow 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.
- ZeikJT 5y agoBrowsers have conditional breakpoints available in their tools/debuggers so you can write them without changing the code.
- tedmielczarek 5y agoI 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/ 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.
- mattmanser 5y agoErr, conditional breakpoints are your friend. Also, "nobody" uses breakpoints? Everyone in my team uses them all the time.
- vagrantJin 5y agoPerhaps 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
- mattmanser 5y agoErr, 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.
- cambaceres 5y agoI assume he referred to breakpoints in the browser.
- quickthrower2 5y agoChrome 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)
- HeavyStorm 5y agoI use it ALL the time. Not sure how people are debugging code nowadays?
- breuleux 5y agoFor Python, but only if execution is deterministic, I made a small library that tries to address that issue: https://github.com/breuleux/breakword 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!