We have to specifically enumerate the scary errors that we'll let actually

stick a fork in the server otherwise malicious or broken code can generate an
AbstractMethodError or some other error and cause the server to decide to quit.

It may still be possible for malicious code to throw an OutOfMemory error, and
if that's the case then I don't know what we can do to both gracefully get the
fuck out of dodge when things are pear shaped and avoid the wrath of the
kiddies.

Incidentally, it was stupidity, not malice that brought this to my awareness.


git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4387 542714f4-19e9-0310-aa3c-eee0fc999fb1

src/java/com/threerings/presents/server/PresentsDObjectMgr.java

@@ -278,12 +278,12 @@ public class PresentsDObjectMgr
                 processEvent((DEvent)unit);
             }
 
-        } catch (Exception e) {
-            log.log(Level.WARNING,
-                "Execution unit failed [unit=" + unit + "].", e);
-
-        } catch (Error e) {
+        } catch (OutOfMemoryError e) {
             handleFatalError(unit, e);
+
+        } catch (Throwable t) {
+            log.log(Level.WARNING,
+                "Execution unit failed [unit=" + unit + "].", t);
         }
 
         // compute the elapsed time in microseconds
@@ -417,12 +417,12 @@ public class PresentsDObjectMgr
                 target.notifyListeners(event);
             }
 
-        } catch (Exception e) {
-            log.log(Level.WARNING, "Failure processing event [event=" + event +
-                ", target=" + target + "].", e);
-
-        } catch (Error e) {
+        } catch (OutOfMemoryError e) {
             handleFatalError(event, e);
+
+        } catch (Throwable t) {
+            log.log(Level.WARNING, "Failure processing event [event=" + event +
+                ", target=" + target + "].", t);
         }
 
         // track the number of events dispatched