"Uncompilable source code" RuntimeException in netbeans_问答_开发者

I'm trying to help another developer who is using Netbeans. When he runs or debugs some code of his in Netbeans (6.9.1) he gets an "Uncompilable source code" RuntimeException. I'm pretty experienced in Java but am more used to IntelliJ, and haven't used Netbeans at all.

I've done it a bit of googling and it seems Netbeans will compile code even with errors, and then throw the RuntimeException at the errors. (Fairly bad behaviour IMO, but I guess some will find it useful.) I've got him to completely rebuild the project with no compile errors, but the RuntimeException seems to still occur. I assume he's got some bad cached class data somewhere deep within Netbeans.

2 questions:

Wh开发者_高级运维at is the best way to clear the cache so we can find out where the uncompilable code is?
Is there any way of turning off this behaviour so the code won't run/debug unless everything will compile, so these RuntimeException's won't be injected into the code?

I've googled a fair bit, but haven't found the answer to either of these questions yet.

Update: More information:

Turning off the "compile on save" option makes the problem go away. Turning CoS back on again brings the exception back. Unfortunately this isn't a fix, as CoS is a very useful option.
http://netbeans.org/bugzilla/show_bug.cgi?id=182009 seems the closest bug report, but it has been closed as "RESOLVED INCOMPLETE". Unfortunately the bug is hard to reproduce - the exception is happening in Java library code, when it calls a third-party library, so there isn't anything at the point the exception is thrown we can change. And the code will work for weeks, and then suddenly start throwing this error with no obvious reason why.
We've tried manually deleting the entire build directory - still not a fix.

We finally got a solution, but still don't quite know why the situation occurs. When you have Compile On Save activated, Netbeans generates a second set of class files for debugging etc. These are stored in $USER/.netbeans/var/cache/index/s*/java/*/classes

Somehow (not sure how) this directory can get corrupted or fail to update.

If you close netbeans, delete $USER/.netbeans/var/cache/index and all subdirectories and restart netbeans this clears the cache. If you have no compile errors, your problem ought to go away at this point.

NB: $USER is your user directory - on Windows 7 this is usually c:\Users\username, I guess on Unix it will be ~username.

If you get this problem please vote for, comment on, or add information to: http://netbeans.org/bugzilla/show_bug.cgi?id=182009

I experienced the same wired problem in NB 7.0.1, my hammer-IQ solution was to make a typo in the source code, run NB with this error (despite an error message) and than the cached class was successfully deleted.

I experienced this issue on Linux Mint Nadia with Netbeans 7.2.1, but was stumped as to where the cache location might be - mine was actually located at

/home/USER/.cache/netbeans/7.2.1

rather than in the .netbeans folder.

If you're not sure where the cache is located on your particular setup, just go to the help > about menu in Netbeans and it'll tell you the correct path.

After realising that the cause was a bad cache from the other posted solutions, I solved this problem by copying the file to another directory, deleting it from NetBeans, and then adding it again.

In fact, you neednt delete whole of index folder. When you open netbeans and your project folder is active. Netbeans starts scanning files and creates temporary project folders (in index folder) for all active projects. If you check index\segments file(its a text file and can be viewed in notepad/(text editor)), you will be able to identify the folders that represent your project. You can then delete those folders and restart netbeans.

*Active project means those projects that were open before Netbeans was shutdown.

Had the same problem on Windows 7 with Netbeans 12.

Cache is here:

C:\Users\<Username>\AppData\Local\NetBeans\Cache

, but the deleting cache is not helpful sometimes. The better solution is to recompile the problematic class i.e. make a minor change (e.g. add space) and save.