Community
Participate
Working Groups
This is with 1.5.1a. I am developing a web application and I ran into this compiler crash. The resource to be copied (Thumbs.db) was in use and therefore could not be copied. However, AJC ended up producing an internal error instead of a warning or a normal error. java.io.FileNotFoundException at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.<init>(FileOutputStream.java:179) at java.io.FileOutputStream.<init>(FileOutputStream.java:131) at org.aspectj.util.FileUtil.makeOutputStream(FileUtil.java:1258) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.writeResource(AjBuildManager.java:504) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.copyResourcesFromFile(AjBuildManager.java:482) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.copyResourcesToDestination(AjBuildManager.java:424) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.doBuild(AjBuildManager.java:320) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.batchBuild(AjBuildManager.java:161) at org.aspectj.ajde.internal.CompilerAdapter.compile(CompilerAdapter.java:122) at org.aspectj.ajde.internal.AspectJBuildManager$CompilerThread.run(AspectJBuildManager.java:191) FileNotFoundException thrown: C:\work\workspace\MyCompany\class\images\Thumbs.db (Access is denied)
The problem is not that the compiler fails, but the message isn't nice. But errors I think are restricted to compile-time errors - not unexpected exceptions stemming from configuration errors. I don't see a clean way around the verbosity, but I agree with the sentiment. It would be nice if for every stack trace stemming from a user or environment error we could guess what the error was a provide instructions on how to fix - or at least note for IOExceptions the affected file in an error message. Here I think the message (at the bottom) is clear enough, but printing the stack might be unnecessary. But I don't think we can know for all these whether to print the stack; we might know it in FileUtil.makeOutputStream(..) or in all the callers thereof, but we can't really call it a compiler error so it ends up being an abort, handled like all the others. Reopen if you disagree, but I don't see a clean fix for this class of problems, and a point fix for this case introduces a new kind of error. It might be that we create a new message kind, AbortWarning, which stops processing but by convention only emits a message and not a trace. that crosscutting smell.
Any stack trace produced by a compiler is very unnerving to user--new or old. It reduces confidence in the tool due to a dobut that there may be more problems not yet known. I don't remember, for example, Javac ever producing a stack trace. Here I can see a nice message produced by the compiler: Error copying resources: C:\work\workspace\MyCompany\class\images\Thumbs.db (Access is denied) Here is an advice that would do the job (not that I am suggesting this as necessarily a good way of implementing, but only as a possible way): Object around() : execution(* FileUtil.makeOutputStream(..)) && cflow(execution(* AjBuildManager.copyResourcesToDestination(..))) { try { return proceed(); } catch (IOException ex) { // or perhaps even Exception printError("Error copying resources: " + ex.getMessage()); } }
*** Bug 142383 has been marked as a duplicate of this bug. ***
I've fixed this - now a proper error is produced for this case rather than a stack trace. My fix is a *bit* like Ramnivas' aspect hand coded ;) fix will be in next dev build.
fix available.
