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.
[dev sep 17] Created some text file from template and got an information box saying "path/file.txt is invalid; you cannot call getNodeDelegate on it". The template wizard then reopened. (Not reproducible.) Clearly something is wrong in datasystems, but this cannot be debugged because somebody is swallowing the stack trace! This would be an IllegalStateException with a detail message but no annotations. Under no circumstances should the Explorer, template wizard, or anyone else catch a runtime exception with no localized annotation and display an information box to the user with the unlocalized detail message, while failing to print the stack trace anywhere (I have netbeans.debug.exceptions=true). Such an exception should cancel whatever was going on (e.g. close the wizard) and display a regular exception dialog as with TopManager.notifyException, which would print the stack trace, hide the detail message, and ask the user to file a bug. It seems TemplateWizard.instantiateImpl is catching the IllegalStateException, which is quite bad--such an ISE could be coming from anywhere, it is a generic internal exception. Unfortunately it was chosen as the documented exception to throw if the filename is wrong--an API bug IMHO. Not clear how this should be fixed--should every instantiate() implementation that does not intentionally throw ISE, enclose its whole body in a catch block looking for random ISE's, and if found notify them and return Collections.EMPTY_SET? This would be quite ugly. DataObject could throw some subclass that TemplateWizard could check for, of course, and throwing a subclass might be desirable anyway (#14844); but a quick search shows about 50 classes just in org.openide.** that use ISE, and most any of these might throw one in the course of a call to instantiate(). A different fix may be needed. Unfortunately this use of ISE has been in the APIs since before release 3.2 and thus must be maintained.
Well, eating ISE and showing just its message is bad, there is almost nothing you can discover in this situation. On the other hand comment in TW code states that current behavior is there due to a backward compatibility. Hopefully, compromise would be using ErrorManager.notify (EM.USER, ise) to show exception's message to user and log stack trace to console and systen.log. Unfortunately TW is messy, I think it's great area for 4.0 refactoring. Fixed in main trunk.
OK, I hope this is good enough UI for cancelled wizards too... seems clear there will not be a perfect solution for this without an API change.
verified
Resolved for 3.4.x or earlier, no new info since then -> closing.