ArcContainerImpl - catch errors during delivery of context events

[mkouba]

• @initialized(ApplicationScoped.class),
  @DESTROYED(ApplicationScoped.class) and
  @BeforeDestroyed(ApplicationScoped.class)

[manovotn]

@mkouba I am probably missing some background but why is it considered 'OK' not to be able to deliver these events? Especially compared to hard fail when the same thing happens for, say, request scope.

And if I read it correctly, then it may happen that you execute several observers, get an exception, dump the rest of them and proceed with application. Given that the order of those OM is not strictly defined, this can lead to weird behaviour in user application as a different subset of OMs can be executed every time before bumping into an exception. Or am I missing something?

[mkouba]

Hm, well the main reason was to fix the behavior when shutting down the container where a failed notification should not affect a proper cleanup. For app init - a notification failure will abort processing of the event as usual but we would like to make sure the CDI.setCDIProvider() is invoked.

[manovotn]

Summing up here what I told Martin over Zulip...

I think it would be more sensible to only catch the errors during shutdown, which means [Before]Destroyed events, not the Initialized one as that might leave user app in weird/undefined state.

ArcContainerImpl also calls terminate on RequestContext which invokes similar events for request context. Those should be changed similarly.

[mkouba]

@manovotn Your comments should be addressed now ;-).

[manovotn]

Since request context can (or even has to) be activated repeatedly during the application run, I don't like much that this will cover up fails even in those cases as opposed to only during Arc shutdown. But I suppose that's alright for now...

[mkouba]

Since request context can (or even has to) be activated repeatedly during the application run, I don't like much that this will cover up fails even in those cases as opposed to only during Arc shutdown.

Note that users can't handle the exception thrown from an observer method during [Before]Destroyed events anyway. So in my opinion it's ok to catch the exception and log a warning instead of rethrowing the exception.