Sure. I had a line like this:
[code]
public static final Icon CLOSE_ICON = new ImageIcon(MyClass.class.getResource("/someFile.png"));
[/code]
This was careless heat-of-development coding so I could see what the icon looked like. I had made a typo in someFile.png, and it was obviously causing an ExceptionInInitializerError.
However, the class wasn't loaded until it was referenced by a particular Action's actionPerformed() method. Because the EDT doesn't apparently get a helpful Thread.UncaughtExceptionHandler installed on it, this error (NullPointerException causing an ExceptionInInitializerError) was getting vaporized into the ether. The observable behavior was clicking on a button with absolutely no effect, no logs, no stack traces, no nothing.
When you then clicked on the button (backed by this action) again, the resultant CORBA barf hit the log files. For whatever reason, the unloadability of this GUI-related class was causing all sorts of hideous CORBA deserialization errors. What's still odd to me is why these manifested themselves as permission errors, and why not the first time.
The problem could probably be solved by installing an appropriate Thread.UncaughtExceptionHandler in the ACC on startup so that, for example, if an Action barfs with a RuntimeException (fairly common, I'd think, at least during development) it would at [i]least[/i] show up in a log file somewhere. Anything after that point is [i]caveat programmor[/i].
Best,
Laird
[Message sent by forum member 'ljnelson' (ljnelson)]
http://forums.java.net/jive/thread.jspa?messageID=204088