RFR: 8043306 - Provide a replacement for the API that allowed to listen for LogManager configuration changes

[Alan Bateman]

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 
replacement methods.

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.

-Alan.