tree aabd8376d59eb9694b7275974045d74ff94022c1
parent 3b1cd580f7d20d7cdcd68185085f9d89c4bacf17
author limpbizkit <limpbizkit@d779f126-a31b-0410-b53b-1d3aecad763e> 1209342163 +0000
committer limpbizkit <limpbizkit@d779f126-a31b-0410-b53b-1d3aecad763e> 1209342163 +0000

Large internal change:

I've replaced MissingDependencyException with ResolveFailedException, and increased the number of places where it's used. We used to have a lot of code that looked like this:
  if (someBadCondition) {
    addError(whatBadThingHappenedMessage);
    return invalidBinding();
  }
Now we do something simpler - we just throw a ResolveFailedException:
  if (someBadCondition) {
    throw new ResolveFailedException(whatBadThingHappenedMessage);
  }

The motivation was to fix some seemingly-unrelated logic: optional bindings to providers weren't working. The problem was that the code that was calling 'addError' didn't know that it was an optional binding, and therefore not an error. This change is pretty much the only thing that could fix that problem, so I think it's worthwhile.

As an added treat, the change also fixed 2 of our 3 known test failures:
1. messaging for injecting  abstract class used to be lame. Now it's good.
2. we never used to complain when leaving a dangling binding, like so:
  bind(Collection.class).to(List.class);
Now we get an error when doing the list binding, and this bubbles all the way up as it should.

Since the change is big I suspect there might be some bug fallout. I'm going to run it against my standard test case (a giant application that uses Guice) to see if there's any regressions. Anything that has regressed will get its own testcase in the coming week or so...

git-svn-id: https://google-guice.googlecode.com/svn/trunk@449 d779f126-a31b-0410-b53b-1d3aecad763e