Please see the newest commit. Added a test as well. The test failed before the fix.

On Apr 11, 2013, at 12:06 PM, Mirco Dotta <notifications@github.com> wrote:

> In org.scala.tools.eclipse.search/src/org/scala/tools/eclipse/search/jobs/ProjectIndexJob.scala:
> 
> > +    }
> > +  }
> > +
> > +  // Logic for how we deal with the various failures that can happen when indexing.
> > +  private def handlers[A]: PartialFunction[Throwable, Unit] = {
> > +    //
> > +    // The presentation compiler is not working. There's no way we can recover
> > +    // from this.
> > +    case ex: InvalidPresentationCompilerException =>
> > +      logger.error(ex)
> > +      cancel()
> > +    //
> > +    // For all other exceptions (CorruptIndex, IOException, etc.) we delete the index
> > +    // on disc and restart the indexing job, thus re-indexing the entire project.
> > +    case otherwise =>
> > +      removeIndexAndRestart
> Lack of knowledge of why we should get the IOExceptions in the first place ;)
> 
> Then it seems wiser to ignore all sources that fail with a IOException, and keep indexing the next source. We could handle this directly in SourceIndexer.indexProject. The result of the indexation should still be a Failure with a custom exception that carries a reference to the sources that couldn't be indexed. It's then up to the caller code to decide what to do with it (for instance, at the moment, we could simply log the name of the files that weren't indexed because of an IOException, so that when it happens we will have some more understanding of what can cause the exception to occur ;)).
> 
> Also, we should have a mechanism to inform the user when these sort of error happens. Please, file a ticket about this.
> 
> —
> Reply to this email directly or view it on GitHub.
>