Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

InternalProvisionException.errorInUserCode discards important context about user errors #1667

Open
michkot opened this issue Mar 9, 2023 · 1 comment

Comments

@michkot
Copy link

michkot commented Mar 9, 2023

There is a special case in InternalProvisionException.errorInUserCode

public static InternalProvisionException errorInUserCode(
ErrorId errorId, Throwable cause, String messageFormat, Object... arguments) {
Collection<Message> messages = Errors.getMessagesFromThrowable(cause);
if (!messages.isEmpty()) {
// TODO(lukes): it seems like we are dropping some valuable context here..
// consider eliminating this special case
return new InternalProvisionException(messages);
} else {
return new InternalProvisionException(
Messages.create(errorId, cause, messageFormat, arguments));
}
}

which has been pre-flagged as TODO by the author of the function (see git blame https://github.com/google/guice/blame/e960b66d3d5931b9cb1aebd49e452e2c489a921e/core/src/com/google/inject/internal/InternalProvisionException.java#L95) as a potential problem, and I was just hit by this - it indeed discard important context!

What was happening is there was:

  • guice's provider of ClassA .get being called,
  • instantiating the actual custom provider ClassAProvider, then calling its .get
  • doing a lot of work, part of it (4 stack frame bellow) is happening in ClassX, doing injector.getInstance for ClassB -> this fails with ConfigurationError
  • the ConfigurationError (with the relevant stacktrace) is discarded in .errorInUserCode, only its message is kept.

What did I observe?
A ProvisionException that talks about failing to provision ClassB, while provisioning ClassA via ClassAProvider. If you look into ClassAProvider construtor, you don't see any ties to ClassB. It does not mention that code of ClassX in anyway in the text or stacktrace.

You have to start debugging ClassAProvider / Guice itself to find out where is the nested Guice error happening / being discarded.

@Malaydewangan09
Copy link

Malaydewangan09 commented Jun 23, 2023

hey! @cpovirk Is this issue still there ?
Do let me know to resolve this .
Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants