Currently, Eclipse provides a global preference "Skip breakpoints during Run to Line" that determines whether breakpoints are honored when performing a Run to Line operation.
While this works for users who consistently prefer one behavior, it can be inconvenient during real debugging sessions where both modes are useful depending on the context. Eg, when navigating through complex code paths, it is often desirable to honor existing breakpoints, whereas when working inside loops or other breakpoint-heavy areas, it can be useful to temporarily ignore breakpoints and force execution directly to the selected line. Switching between these behaviors currently requires repeatedly changing a preference, which interrupts the debugging workflow.
It may be beneficial to provide a way to choose the desired breakpoint behavior directly from the Run to Line action, such as offering separate actions for normal and forced execution (skip breakpoints) or exposing an alternative action in the context menu based on the current preference state. This would allow users to select the appropriate behavior for a particular debugging scenario without modifying a global setting, resulting in a more efficient and flexible debugging experience.
Community
Currently, Eclipse provides a global preference "Skip breakpoints during Run to Line" that determines whether breakpoints are honored when performing a Run to Line operation.
While this works for users who consistently prefer one behavior, it can be inconvenient during real debugging sessions where both modes are useful depending on the context. Eg, when navigating through complex code paths, it is often desirable to honor existing breakpoints, whereas when working inside loops or other breakpoint-heavy areas, it can be useful to temporarily ignore breakpoints and force execution directly to the selected line. Switching between these behaviors currently requires repeatedly changing a preference, which interrupts the debugging workflow.
It may be beneficial to provide a way to choose the desired breakpoint behavior directly from the Run to Line action, such as offering separate actions for normal and forced execution (skip breakpoints) or exposing an alternative action in the context menu based on the current preference state. This would allow users to select the appropriate behavior for a particular debugging scenario without modifying a global setting, resulting in a more efficient and flexible debugging experience.
Community