Matan Lurey

My understanding is `Context|Driver` has the errors, not library, but maybe you're right. Let me play around a bit.

@natebosch I'm not confident we know when that will happen, and lack of this API makes the AngularDart compiler very brittle (and unrecoverable) in some cases.

+1 for validating. I think this is somewhere we probably need all the packages edited at once, with dependency overrides, to validate this all works e2e, and someone from the...

Background issue for Angular specifically: https://github.com/dart-lang/angular/issues/706

While this is P1, I imagine we can't tackle this with the current priorities yet.

I'd like to re-state the priority of this. We're seeing an increasing number of errors both internally and externally that cause our compiler to crash, but would have been totally...

@natebosch: > Should we refuse to allow access to the `LibraryElement` if there are errors? _Probably_ not, though that is an interesting question. The particular issue here is defining "error",...

That's unfortunate :(. I guess step one is just expose the errors and we can always figure out what else we need to do to make the data more useful.

Another option is find a way _not_ to hard code URI_NOT_GENERATED ;)

I personally like `BuildError`, because it could also do other nice things: * Capture the current `primaryInput` (?) * Be extended by clients, i.e. `TemplateBuildError`, `InjectionBuildError` for us