ctubbsii edited a comment on issue #2331:
URL: https://github.com/apache/accumulo/issues/2331#issuecomment-956451489


   Trying to recover from Errors seems like the moldy bread of the Java world. 
Yeah, sure, *maybe* you can cut around the problem, and continue eating safely, 
but it's not a great idea. When mold occurs, you can't trust that there's not 
mold in smaller, less visible amounts on the rest of the loaf. Similarly, when 
an Error occurs, I don't see how you can trust the rest of the state of the 
JVM... especially something like OutOfMemoryError, which can have cascading 
effects on other threads in the JVM, possibly really important ones in your 
dependent libraries or even internal to Java itself. Errors aren't just 
something you can catch, clean up, and have confidence that all is fine 
afterwards... they reflect a serious problem with the overall state of the 
application. Java's own documentation says that these are likely not 
recoverable, so I have a hard time understanding the desire to try to recover 
from them, or the confidence that one will actually be able to pull it off 
reliably with
 out unforeseen consequences.
   
   Even if we were to make OutOfMemoryError in these particular threads not 
terminal, we can't assume Errors in the general case are safe enough to try to 
handle. So, we'd have to start baking in heuristics to try to determine which 
of the "likely not recoverable" errors we believe are more likely than others 
to be able to recover from, and we have to include assumptions about what 
triggered the Error as part of those heuristics. Or, we have to treat them all 
the same, and pass these through to calling client code, to let them decide 
what to do. Either way, that seems likely to increase code complexity, to 
support highly questionable behavior.
   
   If there's a high demand or strong use case for it, I suppose I could 
support the idea of making the uncaught exception handler pluggable via client 
API. But, it really seems like a bad idea to me (for an implementation to do 
anything other than try to shut the JVM down as quickly as possible)... just 
like moldy bread.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


Reply via email to