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.

Bug 4996 - runAtomicAsUser-derived SourceExceptions when modifiers element node properties are not friendly.
Summary: runAtomicAsUser-derived SourceExceptions when modifiers element node properti...
Status: CLOSED FIXED
Alias: None
Product: java
Classification: Unclassified
Component: Unsupported (show other bugs)
Version: 3.x
Hardware: All All
: P4 normal (vote)
Assignee: issues@java
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 1999-12-15 03:32 UTC by Jesse Glick
Modified: 2007-09-26 09:14 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 1999-12-15 03:32:55 UTC
If e.g. the access modifiers of a guarded (FormEd-using) variable are changed (attempted) using an element node in the Explorer, the resulting error message just says "Exception in setter method" wh
ich is not at all helpful. In this case it looks like the actual exception is an InvocationTargetException wrapping a SourceException which may ultimately be wrapping a BadLocationException and so on.
 Somewhere the user should actually see what the problem is--the final dialog does not display any info about the exception at all.

This is only partially the problem of the element nodes--really there should be some sort of better convention for when to display exceptions from any modified property. Ian suggested at one time that
 there be a marker for exceptions with a reasonable display name, perhaps where the regular and localized detail messages differ, perhaps something else--in this case we should make sure this kind of
thing will properly propagate what is originally the Editor`s message about the guard blocks.
Comment 1 Jan Becicka 2001-01-15 12:32:59 UTC
[010111_1] Attempt to modify text in guarded block invokes error message
saying "Attempt to insert into guarded block at position #". This is correct
behavior.
Comment 2 Quality Engineering 2003-07-01 13:17:35 UTC
Resolved for 3.4.x or earlier, no new info since then -> closing.