Archived
This forum has been archived. Please start a new discussion on GitHub.
Ice for java and Runtime.halt()
Stumbled on this gem today, in IceInternal.Selector.select():
I don't want to make a mountain out of a molehill -- I haven't spent any time investigating when java.nio.channels.Selector.select() might throw an IOException, and if it was a common occurence I'm sure this code wouldn't still be here.
But regardless of how rare the situation might be, Ice has no business bringing the entire JVM down.
There's a similar situation in IceInternal.IncomingConnectionFactory.message(), when the listening process exceeds its FD limit.
catch(java.io.IOException ex) { // // Pressing Ctrl-C causes select() to raise an // IOException, which seems like a JDK bug. We trap // for that special case here and ignore it. // Hopefully we're not masking something important! // if(Network.interrupted(ex)) { continue; } try { String s = "fatal error: selector failed:\n" + ex.getCause().getMessage(); _instance.initializationData().logger.error(s); } finally { Runtime.getRuntime().halt(1); } }
I don't want to make a mountain out of a molehill -- I haven't spent any time investigating when java.nio.channels.Selector.select() might throw an IOException, and if it was a common occurence I'm sure this code wouldn't still be here.
But regardless of how rare the situation might be, Ice has no business bringing the entire JVM down.
There's a similar situation in IceInternal.IncomingConnectionFactory.message(), when the listening process exceeds its FD limit.
0
Comments
-
Similar situation with the C# bindings -- 3 instances of System.Environment.FailFast in ConnectionFactory.cs (when accept() fails for lack of FDs).0