This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
| Summary: | Delete Breakpoints when they lose Context | ||
|---|---|---|---|
| Product: | debugger | Reporter: | bht <bht> |
| Component: | Code | Assignee: | Martin Entlicher <mentlicher> |
| Status: | NEW --- | ||
| Severity: | normal | CC: | markiewb, medeag |
| Priority: | P3 | Keywords: | 7.4_WAIVER_APPROVED, API |
| Version: | 7.3 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Attachments: | The proposed API change with implementation. | ||
|
Description
bht
2013-02-21 08:26:46 UTC
I am changing this from enhancement to defect, in the context of another bug 232670. I cannot create a test case for bug 232670. My thinking is that these old breakpoints have more negative side effects than what their perceived value is. The problem is, that currently method/field/exception breakpoints are not bound to any particular file. They just live in the debugger settings and wait for the suitable element to appear. To fix this, it's necessary to introduce an association of these breakpoints with some particular class' URL and then changes in such classes can be reflected in changes/elimination of the breakpoints. Created attachment 138990 [details]
The proposed API change with implementation.
In order to implement this, we need an API change to be able to associate breakpoints with source file URLs. The proposed API change introduces BreakpointURLHandler class, which is debugger core API, as it can be used for other languages as well. It takes care that the breakpoint is removed when the source file is removed and that it's moved to a new URL on file renames and file moves. Then all Java breakpoints have getURL()/setURL() methods and they listen on changes in class index. Please review the proposed API change. Thanks. We should also use ErrorsCache in the implementation so that we do not remove breakpoints on elements that were temporarily dropped from the AST due to errors in the code. During the review, we have found this change to be risky so close to the end of the release cycle. The risk is, that the user might unexpectedly lose their breakpoints. This can happen as a result of a bug in the implementation, or inconsistent class AST structure, or e.g. switch to a different branch in the version control system, that change the content of classes. Due to this I propose to defer this fix for the next release and waive this issue for NetBeans 7.4. *** Bug 210501 has been marked as a duplicate of this bug. *** According to priority guidelines, this issue is a P3 issue. There's an easy workaround - delete unnecessary breakpoints from Breakpoints window. There is a benefit of automatically deleted breakpoints, but there's also a drawback of loosing such breakpoints e.g. on branch switch. It'd be best if we can have an integration with version control system, which would also manage task-based breakpoints. That would solve this problem. But this is not in the work-plan yet... "There is a benefit of automatically deleted breakpoints,..." What is the benefit you are talking about? In case of the eclipse formatter plugin - which seems related to this - breakpoint getting lost on a reformat of a file, is actually slowing me down. This Bug realy makes it nearly impossible to work with the eclipse formater plugin, disabling 'format on save' helps while debugging. As with maven projects it is so easy that everyone can use his favourite IDE, shared formating is a must. The eclipse formater plugin is currently the only way I know to achieve this... (In reply to mohnid from comment #10) > This Bug realy makes it nearly impossible to work with the eclipse formater > plugin, disabling 'format on save' helps while debugging. > As with maven projects it is so easy that everyone can use his favourite > IDE, shared formating is a must. > The eclipse formater plugin is currently the only way I know to achieve > this... FYI: I updated the eclipse formatter plugin to preserve breakpoints. But unfortunately the preservation of linebreakpoints is still not supported. See https://benkiew.wordpress.com/2014/10/13/new-version-of-eclipse-code-formatter-for-java-plugin-1-8-0-4/ |