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: | AssertionError at org.netbeans.modules.form.layoutdesign.support.SwingLayoutBuilder.fillGroup | ||
|---|---|---|---|
| Product: | guibuilder | Reporter: | Petr Dvorak <joshis> |
| Component: | Code | Assignee: | issues@guibuilder <issues> |
| Status: | VERIFIED WORKSFORME | ||
| Severity: | blocker | CC: | jglick, johanandren, pribyl |
| Priority: | P3 | Keywords: | RANDOM |
| Version: | 6.x | ||
| Hardware: | All | ||
| OS: | All | ||
| URL: | http://statistics.netbeans.org/exceptions/detail.do?id=37796 | ||
| Issue Type: | DEFECT | Exception Reporter: | 37796 |
| Attachments: | stacktrace | ||
|
Description
Petr Dvorak
2008-03-18 11:51:45 UTC
Created attachment 58564 [details]
stacktrace
I am sorry, I am not able to reproduce this issue. Could you, please, provide more details. It would be ideal to attach the corresponding .java and .form files (saved in the last good state) and describe _exact_ steps that should be done to see the exception. Thank you in advance. It is not reproducible after regular (I didn't find scenario) steps. However, I did reproduce it. Just put like 5 panels in the JFrame and play with them: resize, remove, change their order, encapsulate them to each other, ... just play with the panels in the JFrame... Adding a keyword RANDOM I doubt there is anything random in this problem. The layout algorithm used in GUI builder produce always the same result, but the result may depend heavily on small details (e.g. where exactly is the component dropped etc.) It doesn't help at all to suggest me "just play with the panels in the JFrame...". This bug report is useless without exact steps to reproduce. Well, first - I adore your attitude. "The bug report is useless" - it was submitted using built-in bug reporter, demand your colleagues. Second, you made a great observation - computers are in principle deterministic machines, so anything that happens there is potentially reproducible and there are definitely no "random" issues (if we don't count the cosmic rays and stuff, that are deterministic as well though). However, if you follow the guidelines from http://www.netbeans.org/issues/describekeywords.cgi, you will see that this issue matches the definition of RANDOM, as it speaks only about ability to reproduce and frequency (that's what random means). When anyone is able to reproduce the issue, he/she will remove the RANDOM keyword, up till now it remains there. Assigning a RANDOM keyword again. If you think the issue is so easy, you will be definitely able to reproduce it from the stack-trace, just like anyone else does. Second, when I work with the IDE, there is like 20 exceptions a day. If I was just a regular user of NB, I would be pretty frustrated. The suggestion was quite accurate - you can get an exception quite often (I don't even send all of them) if you just play with the panels. Finally, I will do my best to reproduce it, as soon as I can manage to do that, I will let you know. OK, let's clarify my last comment that made you so offended.
I don't want to start a flame war or philosophical discussion about randomness in computer science. I believe that
RANDOM keyword belongs to issues that are not always reproducible if you repeat the same user gestures in the IDE e.g.
the result may depend for example on thread scheduling (e.g. things that user cannot affect). By removal of the keyword
I just wanted to point out that this is not the case here. I see that you have a different oppinion on that. Hence,
feel free to keep the keyword there if you want to (it doesn't harm anyone). The essence of this comment was to make
you aware about subtle differences when placing/resizing/moving components in Free Design. If you concentrate on them
then you have a better chances to provide reproducible test cases.
> If you think the issue is so easy, you will be definitely able to reproduce it from the stack-trace,
> just like anyone else does.
Some problems can be identified just from the stack trace and make sure that I always scan the source code to guess
what can cause the problem. Unfortunately, it is not possible in GUI builder quite often. The exception is usually
thrown by some low-level algorithm that got into an unexpected state and it is not clear (without the knowledge of the
context e.g. the form) why this occured and what should be done in this case.
This is also the reason why this bug report is not usefull without exact steps to reproduce, unfortunately. Note, that
it does not help to tell me to find the problem myself. Why would I need a bug tracking system and quality engineering
with this approach?
jstola, you don't need to worry :o) - I was not offended. I was more surprised - the stack trace tells you that it is
not an exception, but an assertion error. Furthermore, there are modules and exact line numbers specified. I didn't
expect any complications with resolving this issue then.
Java.lang.AssertionError
at org.netbeans.modules.form.layoutdesign.support.SwingLayoutBuilder.fillGroup(SwingLayoutBuilder.java:266)
at org.netbeans.modules.form.layoutdesign.support.SwingLayoutBuilder.composeGroup(SwingLayoutBuilder.java:232)
at org.netbeans.modules.form.layoutdesign.support.SwingLayoutBuilder.fillGroup(SwingLayoutBuilder.java:251)
at org.netbeans.modules.form.layoutdesign.support.SwingLayoutBuilder.composeGroup(SwingLayoutBuilder.java:232)
I submitted the issue using the built-in exception reporter, I could have also just let it go, but " Why would we need a
bug tracking system and quality engineering with this approach?".
I got the same issue about 3-4 times just yesterday - it appeared intermittently and I didn't manage to reproduce it.
> RANDOM: This issue occurs intermittently and cannot be reproduced reliably.
If you are at work we can discuss it on coffee break.
Closing the issue as non-reproducible for now. Feel free to reopen if you are still able to reproduce it, but don't forget to provide exact steps to reproduce then. Thank you in advance. Verified Reopening - reproduced in NetBeans IDE 6.5 Beta (Build 200808111757) http://statistics.netbeans.org/exceptions/detail.do?id=131399 This issue was reopened by Exception reporter, unfortunately no additional info that could help to reproduce the problem can be found in the report. I still cannot reproduce this :/ Closing for now as WORKSFORME. If anyone manage to reproduce this reliably, please reopen. Thanks V. *** Bug 180298 has been marked as a duplicate of this bug. *** (In reply to comment #11) > This issue was reopened by Exception reporter, unfortunately no additional info > that could help to reproduce the problem > can be found in the report. That just means that the assert statement is inadequate. The form module needs to be fixed to somehow audit actions that are taken by the user and their effect, so that if and when a seemingly impossible situation is encountered, the assertion error includes all the information needed for a developer to diagnose the problem. |