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.
[200311130740] Steps to reproduction: ---------------------- 1)Delete ColorPreview class from example. 2)Open ColorPicker ClassNotFoundException thrown because ColorPicker form uses ColorPreview component.
Created attachment 12138 [details] exception stacktrace
Form editor correctly reports that component class cannot be loaded, which is IMHO quite understandable if you delete the class. Why do you think it is a bug?
at least the exception is not annotated. On opening form there should be better to show user friendly message instead.
The exception is annotated. When I try it I get a dialog explaining what happened. See attachment. It is not friendly?
Created attachment 12150 [details] error dialog
Still not convinced this is a bug...
I tend to agree with Petr. First, the title of the dialog box says "Exception" which is not very helpful. Second, the message text says "component could not be loaded" three times (!) in different words, but it doesn't provide any hint why. Third, the exception stack-trace shown after the Show Details button is pressed, doesn't help the user either. I understand this is rather a general problem and there are other examples like this in the IDE. However, it doesn't make this a non-issue. P3 -> P4.
To be honest, your comments are not much helpful either ;) I know what you don't like, but don't know how it should behave correctly then. Let's look at it more closely. > First, the title of the dialog box says "Exception" which is not very > helpful. Well, this is in fact a problem of user component - its class cannot be found. So it is basically problem in user data (or code), not in form editor code. So it is an exception. Hidding this fact from the user does not make sense. > Second, the message text says "component could not be loaded" three > times (!) in different words, but it doesn't provide any hint why. The best hint you can give to the user about her code is to give her the exception as the root cause of the problem. It is IMO most helpful for a developer. Form editor might provide intelligent messages based on type of exception and conditions when it happanes, but IMHO this is not the problem in current state (saying "class cannot be loaded" for ClassNotFoundException should be enough). The only ugly thing is the last repeating of the "Component cannot be loaded". Instead, we could provide a advice like "Check if the class is compiled and available in mounted filesystems." That can be done. But the rest is IMO OK. If you don't agree, please consult this with HIE.
I strongly disagree with your IMHO. The developer of form, jdialog is user of netbeans. At first sight the exception looks like bug in netbeans. The exception is writen to ide.log like error. Can you tell me which line of stacktrace is so important for user? IMHO for java beginner it must be very dificult to understand to this stacktrace. Let's me show you other example: User tried to delete java file in filesystem. Are you really sure that it is good idea to show exception if file is read only? IMHO not.
I agree with Petr's first paragraph. It looks like a bug in the IDE which it is not. Then the IDE should not provide the user with an exception (moreover logged into ide.log), but rather with an error message followed by the useful hint such as the one proposed by Tomas. Although I agree with Petr's second paragraph too, it is not a form module issue, so let's not discuss it here.
Okay, I see your point - the user might be confused by "Exception" title. What is the right title then? Warning? Ccing Dusan for advise.
It seems to me, that Error dialog will solve this issue. And mentioned text "Check if the class is compiled and available in mounted filesystems." could be used too. For guideline check this link: http://java.sun.com/products/jlf/ed2/book/HIG.Dialogs5.html#35722
*** Issue 40201 has been marked as a duplicate of this issue. ***
*** Issue 38839 has been marked as a duplicate of this issue. ***
*** Issue 32356 has been marked as a duplicate of this issue. ***
Error handling was changed in the last few relases => closing as fixed.