Exceptions during @PostConstruct are quietly ignored, but lead to failures later

[lstreepy]

I am seeing a problem with Weld 3.0.0 Alpha10 where if a runtime exception is thrown from within an @PostConstruct method on an @ApplicationScope bean, the exception is never reported and the bean instance fails to be added to the Application context.  This leads to strange behavior later (w.r.t. event delivery since a new, second, instance is created in order to deliver the event).

Is this expected behavior?  I would think not and the Weld core should report the exception (which it obviously caught in some manner).

Thanks,

Larry.

[mkouba]

Hi Larry,

could you describe your use-case in more detail? Weld usually wraps and rethrows the exception. Whether the problem is reported or not depends on the context, i.e. the situation in which the contextual instance is created.

[lstreepy]

Sorry for the delay, email problems and I didn't get notification that you had responded.

Not too much more detail than:

1. Running in an SE environment, we have multiple containers.
2. A typical @ApplicationScope bean that has a method annotated with @PostConstruct
3. When the container instantiated it (to satisfy an injection point in another App scoped bean) and invoked the post construct method, an NPE was thrown in some subordinate code.
4. The container apparently caught and did not report the exception, and it wasn't added to the App context.  I debugged this at the time down into the Weld code, but don't have exact details for you.  I did inspect the App context after the attempt to construct the bean, and confirmed that the instance was not present.
5. Later, a method in that class that @Observes an event was triggered, and it tried to construct another instance (since the first failure resulted in it not being in the context), which led to application failures since the initial post construct logic had not completed.

If need be, I can try to recreate the failure mode (we've since corrected our code to avoid the problem).  Just let me know what additional information you need.  Thanks for your help.

[mkouba]

Yep, a simple reproducer/test application would be really helpful. If it was too complicated to extract the beans then the way "a typical @ApplicationScopes bean" is created/accessed might be interesting info.

[lstreepy]

Ok, a little more info and an example to reproduce it.

One key was that the invocation of a method on the App scoped bean was happening in a SwingWorker, which has an evil habit of eating exceptions and not reporting them.  So, in the example (which is a maven project that I've attached, just run the command in "runme" to execute it), I wrap the invocations in a try/catch to mimic that behavior.  So, it appears that the Weld core doesn't report the failure, but it does wrap it in a WeldException and throws that, which I'm assuming is the desired/correct behavior for Weld?

So, this is something that I'll probably need to handle in our application infrastructure if this is expected behavior from Weld.

Thanks,

Larry.

[mkouba]

Yes, this is expected. Weld wraps checked exceptions - in this case java.lang.reflect.InvocationTargetException which holds the NPE in its target field.