[ https://issues.apache.org/jira/browse/ZOOKEEPER-1442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13263311#comment-13263311 ]
Rakesh R commented on ZOOKEEPER-1442: ------------------------------------- It looks nice, I just have one small comment about reflection usage. I don't see any logic to use reflection until not supporting new user defined custom strategies, instead can we make it simple by putting the instance directly to the HashMap? like, {noformat} handlerMap.put(LogOnlyExceptionHandler.name().toLowerCase(), new LogOnlyExceptionHandler()); {noformat} > Uncaught exception handler should exit on a java.lang.Error > ----------------------------------------------------------- > > Key: ZOOKEEPER-1442 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1442 > Project: ZooKeeper > Issue Type: Bug > Components: java client, server > Affects Versions: 3.4.3, 3.3.5 > Reporter: Jeremy Stribling > Assignee: Jeremy Stribling > Priority: Minor > Attachments: ZOOKEEPER-1442.patch, ZOOKEEPER-1442.patch, > ZOOKEEPER-1442.patch > > > The uncaught exception handler registered in NIOServerCnxnFactory and > ClientCnxn simply logs exceptions and lets the rest of ZooKeeper go on its > merry way. However, errors such as OutOfMemoryErrors should really crash the > program, as they represent unrecoverable errors. If the exception that gets > to the uncaught exception handler is an instanceof a java.lang.Error, ZK > should exit with an error code (in addition to logging the error). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira