Say you make a change to a property value which results in an error (either an
explicit one or because the file is read only). In FFJ 3.0 (I think that was
based on NB 3.2, but I forget now), you get an nice dialog with the error no
matter if you make the change from the popup editor or the in place editor. In
NB 3.3.1, you only get the dialog from the popup editor. From the in place
editor, the change is not accepted, but there is not user feedback anymore.
I'll attach a test program which demonstrates this.
Created attachment 4817 [details]
Test program which demonstrates the problem
Created attachment 4941 [details]
The patch was applied. Annotate and notify of a exception in property
setting was unified in PropertyPanel and a custom editor.
added 3.3.2_CANDIDATE keyword per Rochelle's request
Merged in orion_fcs branch.
verified in [nb_dev](20020329) && [orion](020326)
verified in [orion_CE](20020401) && [jdk1.3.1](03)/[jdk1.4](fcs)
In 3.4 beta 3 and FFJ 4.0 FCS, the dialog ignores the level used in
the annotation. For example, run the test program and type "illegal"
into the property sheet.
In FFJ 3.0: Error dialog with error graphic
In FFJ 4.0/3.4 dev: Information dialog with info graphic
The FFJ 3.0 behavior is the correct one since the code explicitly sets
the level to ErrorManager.ERROR. We can discuss the default behavior
separately. Please see
Jano, could you look an this issue? Add ui team's point of view and
reassign back. Technically is not there a problem change severity by
final resolve. Thanks
I don't understand the last comment. This is a regression in behavior
when the programmer explicitly specifies an annotation with
ErrorManager.ERROR. The ui team's point of view should only be
considered for the default behavior. In my opinion, that should be
Sure, this does not need ui decision. If exception is annotated with
error annotation, it should display error dialog. The default dialog
is separate issue.
Created attachment 7355 [details]
a experimental patch
Aha, I was wrong in my insight into problem I have apologized.
I attached a experimental patch. The severity is extracted from the
annotation. But there is not any plan how a severity select from
annotations. Should be select the highest severity or lowest? Or
should be the last attached annotation?
There is a common assumption that exceptions are notified by USER
severity, many exceptions are default annotated as EXCEPTION but
shouldn't be notified with EXCEPTION severity.
The assumption that my severity should be retained is in opposite.
Try apply a patch, test program passed ok but the illegal state in
modifiers editor was badly notified as exception.
Do you have some proposals how solve it?
Please check how the code in FFJ3.0 worked - that was correct. In my
opinion, you should extract the severity from the same annotation
which contains the localized message for the dialog. In no
circumstances should the exception be shown, though. The severity
should only affect the title/button/graphic of the dialog descriptor.
reassigning to the new subcomponent owner
keyword 3.3.2_CANDIDATE, TM=FFJ4.0 are obsolete now, not fixed yet
Jiri, we should talk about this issue sometime.
Could we limit it to a handful of exceptions, and ignore the
severity? In other words, for example, show a user msg dialog
for IllegalArgumentException, but not for others? And don't show
it if there is no localized message?
The situation I want to avoid is the problems with the older code,
where you could get something like an ArrayIndexOutOfBoundsException
with a useless message, and the user sees a cryptic dialog that
IllegalArgumentException is a reasonable thing to throw for
wrong user values (PropertyVetoException would be better, but
it's checked, and so incompatible). What won't work about it?
I've updated the error handling code in some of the core property
editors and the new property sheet, and haven't seen this problem
It is critically important that all property editors that want to
notify about bad user input annotate the exceptions correctly.
This means adding a localized message and using USER level severity.
This should work in the core editors now; if there are individual
editors which don't handle things correctly, please file individual
issues - their annotation code needs to be corrected.
Fixed - new property sheet committed. As mentioned, if
you are still seeing stack traces from individual editors,
please file issues against those editors. The property
sheet will handle an exception correctly if the editor
annotates the exception correctly.
Works in 7/10 build.