Bug 28160

Reassigning to the Editor - that's where the exception is probably 
reported. Does it appear as "unexpected exception" dialog box, or is it 
some nicer message ? 
 

Svata,
what's wrong on calling getSource() on SourceCookie as it is done in
JCUpdater.isValidMountPoint method?
The method SC.getSource() doesn't declare it throws IOE.
Should the SourceCookie be checked somehow for validity?

IOException is lost in the ClassDataObject.getClassFile()...
Reassigning back to clazz module.

Petr, which version/build is it ? Line numbers do not match sources on 
3.5 branch. 

Petr -- this is only a message printed to the log file, isn't it ? There's a 
hardcoded printStackTrace in the classfile module; attaching 
suggested patch. 

Created attachment 9366 [details]
Suggested patch

Swata I cannot reproduce it and a cannot remember to my invalid class
and build. After I saw to your patch you have right that the 
exception was printed to log file. But why you don't add to your code: 

} catch (IOException ioe) {
   Exception newExc = new Exception("invalid class");
   ErrorManager.getDefault().annotate(newExc,ioe);
   throw newExc;
} 

Because the original code looked strange to me - one IOException
catched and another thrown -- I do not know why the original one was
not passed up. So I proposed only a minimal change.
Anyway, if the inner exception contains some useful data, your code is
definitely better.

I've removed the printStackTrace line from ClassFile.java, and will
commit it when I am back outside of Sun's firewall tonight. 

The reason the original exception isn't thrown is because the message
associated with it doesn't describe the real problem, which is that an
invalid class file/stream was passed to the library.  When 1.4 becomes
the minimum API, this can be changed to use its exception chaining.

Perhaps a ClassFormatError is a more accurate exception, but the
reason I don't throw a ClassFormatError is because that error is
unchecked.

I updated the exception message as you requested in ClassFile where
files or filenames are used.  However, the ClassDataObject is opening
the ClassFile using a stream, and so I don't have the original class
name to report in the exception message.  The clazz module therefore
needs to either catch the IOException and throw a new one with a
better error message, or annotation the exception.

Additionally, the classfile module is not really a module, but just a
library with no NetBeans dependencies; it has a module manifest just
to support the auto-update feature.  So any ErrorManager annotating
has to be done by its clients.

I don't currently have commit rights for the clazz module, but would
be happy to make the above changes to ClassDataObject if given that
privilege.

This issue is opened for long time and I cannot reproduce it. 

v