3 ms·
Not very convinced yet. I would expect it to fail/not work quite quickly for cases which are "worth" debugging. For the first example I would just place the br
by Calzifer 3y ago
Not very convinced yet. I would expect it to fail/not work quite quickly for cases which are "worth" debugging.
For the first example I would just place the breakpoint on the return. The highlighting is quite nice but I see not much need for the prediction which was probably hard to implement.
In languages like Java features like "hot code replace" exist. In a function like this if the result is not what I expect, I can simply change the code and restart the function without restarting the application. Not much need for prediction.
What I wished were more common is reverse debugging were you can step backwards.
- yodon 3y agoWow. Your description of Time Travel Debugging plus Edit and Continue working together sounds amazing. Definitely want to try that some day. I suspect the side-effect/impure-function-call detection JetBrains has built here will be key to understanding boundaries of where/when you can roll back, edit, and continue, and where/when you can't.
- matkoch 3y agoDid you see the part about live edits? Placing the breakpoint at the return would be too late to have that working. Edit: or maybe that was your point after all?!