I followed this particular exception from its source, and found that it didn't get reported in the usual way (dialog box) because the job that has the error (ClassPathContainerUpdateJob) decided to log the error and return a "cancel status" rather than notify job manager of the problem by returning an error status.
I think in general we are trying to raise appropriate exceptions when something/anything goes wrong in executing grails commands. But we also need the contexts in which those Exeptions occur to handle them appropriately.
In this case, I think the job in the past tended to generate too many spurious errors, which is why its error were being "silently" muffled away. But with the better handling of the sequencing of stuff that happens after grails commands get executed, this job now doesn't seem to cause spurrious errors anymore (errors tend to be real problems now), so I've changed it to propagate the error to the Job scheduler, which in turn will show a dialog to the user.
I've tested it a bit and it looks stable. The error dialog looks reasonable and seems to appear at the right times (e.g. when you import a grails project and there's no Grails install, or when you try to run Refresh dependecies manually and there is not Grails install. So I'm going to commit it shortly.