consider alternatives to global uncaughtexceptionhandler
|Keywords:||Affected PuppetDB version:|
This ticket is just an attempt to capture some thoughts that came up during discussions about this pull request:
In order to decrease our odds of swallowing important and useful error messages during startup, we’ve registered a global uncaughtexceptionhandler in the JVM. This is a good thing for the time being, but we should revisit the decision at some point. Because it’s possible that many other tools could be sharing the JVM with us, using the global uncaughtexceptionhandler is probably not a great idea. We are already running an embedded instance of ActiveMQ and potentially HSQL in our JVM; if one of them were to also attempt to set the global handler, it could cause us problems. (It seems relatively safe to assume that these two tools in particular will not do this, but it’s possible that other tools / libraries that we integrate with in the future might do so.)
Further, if we wish for others to potentially be able to embed an instance of puppetdb in their own JVM application in the future, we’re not being great “citizens” by relying on this global handler.
Thus, a couple of things we should consider:
- Make sure that this only ever happens in our equivalent of a “main” method; as long as it doesn’t happen inside of any of the “re-usable” parts of our code, it shouldn’t be too big of an issue.
- Explore the possibility of writing a custom subclass of Thread or ThreadPool, wherein we would have the ability to set per-thread uncaught exception handlers without modifying the global handler.