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.
If I have a file open in NetBeans and delete that file outside of NetBeans, when I come back to NetBeans it throws NPEs while closing those windows. No prompting or asking whether I want to re-save those files, so if I had any unsaved edits they'd be lost. For comparison, Eclipse tells you the file has gone away and asks if you want to save what you have, recreating the file. Obviously it doesn't NPE. This is NB6 M4, OS X.
I believe FileObject does have isVirtual(), originally used for files that existed in some remote storage but did not exist locally. I'd imagine MasterFS could handle unexpectedly deleted local files by keeping the file valid but making isVirtual true and returning an empty input stream, and the necessary places would need to check that. Either way, NPEs on a file being deleted are bugs - it's a condition that should be handled relatively gracefully.
I cannot reproduce in a dev build on Linux. 1. Create a text file, open it in NB (--open), go to a terminal and delete it, switch back to NB. File is closed. 2. Create a file, open it in NB, edit but do not save changes, go to a terminal and delete it, switch back to NB. Prompt to save/discard/cancel appears. Choose Save. File recreated on disk, with edited content. In no case do I get an NPE. Anyway the stack trace is missing so this cannot be diagnosed until it is attached.
This is expected behaviour, which worked this way for years. The problem is most probably related to some special file type which adds some additional handling and fails. What kind of file was the problematic one?
Stack trace below. It appears to only happen when several files are deleted. java.lang.NullPointerException at org.netbeans.modules.javacore.parser.ASTProvider.getToken(ASTProvider.java:337) at org.netbeans.modules.javacore.parser.TokenIterator.getNextTokenType(TokenIterator.java:69) at org.netbeans.modules.javacore.scanning.JavaUpdater.makeIndex(JavaUpdater.java:102) at org.netbeans.modules.javacore.scanning.JavaUpdater.computeIndex(JavaUpdater.java:64) at org.netbeans.modules.javacore.jmiimpl.javamodel.ResourceImpl.directUpdate(ResourceImpl.java:719) at org.netbeans.modules.javacore.jmiimpl.javamodel.ResourceImpl.checkUpToDate(ResourceImpl.java:650) at org.netbeans.modules.javacore.jmiimpl.javamodel.ResourceImpl.checkUpToDate(ResourceImpl.java:593) at org.netbeans.modules.javacore.jmiimpl.javamodel.SemiPersistentElement.isValid(SemiPersistentElement.java:74) at org.netbeans.modules.java.navigation.ClassMemberRelatedItemProvider.getPrimaryItemFromNodes(ClassMemberRelatedItemProvider.java:56) at org.netbeans.modules.java.navigation.spi.RelatedItemProviderSupport$ActiveNodeSupport.findPrimaryItem(RelatedItemProviderSupport.java:365) at org.netbeans.modules.java.navigation.spi.RelatedItemProviderSupport$Updater.run(RelatedItemProviderSupport.java:263) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:541) [catch] at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:963)
exception from javacore - reassigne
The code in question is gone in M5 anyway.
Reorganization of java component