Good News! We are ready to roll out the enhanced Better Breakpoint feature!
Two months ago, we released the Better Breakpoint beta that provided more options to make your debugging better than ever before. Thank you for all your testing and feedback. Now, after having spent time fixing bugs and enhancing performance, we’re proud to provide you with:
DevHub documentation, step-by-step guidance on how to use breakpoints in debugging.
Consolidated icons for standard breakpoints, logpoints and conditional breakpoints in different statuses.
Today, we are launching Better Breakpoints as a default-on Beta for a small but meaningful cohort of the Studio user base. Over the next few weeks, we will progressively ramp up to 100%. If you’ve opted into the beta before today, you will not be affected by this process. In the meantime, we will closely monitor crashes and errors. If any significant issues are uncovered, we will roll the feature back to opt-in Beta.
You see, I think that’s a great candidate for logpoints, or better yet, the breakpoints that have “Condition”, “Log Message” and “Continue Execution” set. Some bugs are quite obscure and you don’t want to halt the execution time, because it may be tied to the real time, or even add a single line of code with conditionals and so, much less write code to debug the original code and make a mistake doing it.
The long term plan is along these lines; there is a lot of groundwork to be laid in order for it to be usable in a meaningful way. Are you thinking about creating your own Debugger UI? Is there anything in particular that might be addressed before DebuggerManager is exposed?
It’s great to hear that print debugging is working well enough for you.
The Debugger is a tool and as long you don’t feel the need for something more than print you should keep using print, just like as long as you don’t need a motorized excavator, you should use a shovel. In fact I wouldn’t let in one of those excavators into my backyard.
There are use cases that only print can do right now (for example production debugging) and use cases that only the debugger can do (for example stepping through code or changing what gets printed without stopping the code).
The Debugger features are just tools that can be used to help and maybe speed up coding for more devs so it’s more like additional options than an “either this or that” choice.
Nice, and you should stay tuned for the new API and give feedback on that one as well. We’re definitely doing our best to improve extendability – with stability, scalability and security in mind.
