RFR: 8043306 - Provide a replacement for the API that allowed to listen for LogManager configuration changes
Alan.Bateman at oracle.com
Mon Sep 15 07:33:30 UTC 2014
On 12/09/2014 17:54, Daniel Fuchs wrote:
> For this patch - I think that our options are limited to the alternative:
> 1. propagate the exception
> 2. catch and silentlty drop the exception
> What is the 'better' behavior (and I agree neither of the two are ideal)
> probably depends on what is the typical use case for these listeners.
> My assumption is that in most cases - there will be a single listener, in
> which case 1. is probably better. I haven't seen any bug complaining
> about how exceptions were handled in the previous implementation,
> though I have seen some complaining about swallowed exceptions...
> That said - if there is consensus that 2. is better - I have no real
> objection except those stated above.
As you point out, the choice isn't great. #1 has been the long standing
behavior (since JDK 1.4) and I'm not not aware of any comments or
complaints. At the same time usage was extremely rare so the opportunity
to even notice this was rare. I expect this will be the same with any
If you go with #1 and only fail after all listeners have been notified
then it might not be too bad. It would of course require special-casing
ThreadDeath, maybe others, as would option #2.
More information about the core-libs-dev