[
http://www.stripesframework.org/jira/browse/STS-690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11709#action_11709
]
John Newman commented on STS-690:
---------------------------------
ok through the debugger I found the actual error I am getting is:
java.lang.OutOfMemoryError: Java heap space. That explains why this was only
happening rarely.
I was always taught not to catch Throwable, because you'll catch things like
java.lang.OutOfMemoryError, that, well, aren't supposed to be caught. If you
do catch an out of memory error: now what? LinkageError etc. My
ExceptionHandler class really shouldn't have a method for those, right?
I temporarily added a Throwable method to my exception handler class and I am
able to log it myself now. But if I remove my exception handler and use the
default one that ships with stripes, it doesn't get logged like it should, so
IMO this is a bug.
> "ActionBean execution threw an exception" - root cause is not logged
> --------------------------------------------------------------------
>
> Key: STS-690
> URL: http://www.stripesframework.org/jira/browse/STS-690
> Project: Stripes
> Issue Type: Bug
> Components: ActionBean Dispatching
> Affects Versions: Release 1.5
> Reporter: John Newman
>
> hello,
> Perhaps I have something configured wrong. But occasionally I get this error
> here, with no help as to what I actually have wrong:
> 10:50:25,230 WARN DefaultExceptionHandler:90 - Unhandled exception caught by
> the Stripes default exception handler.
> net.sourceforge.stripes.exception.StripesServletException: ActionBean
> execution threw an exception.
> at
> net.sourceforge.stripes.controller.DispatcherServlet.doPost(DispatcherServlet.java:190)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
> at
> net.sourceforge.stripes.mock.MockFilterChain.doFilter(MockFilterChain.java:66)
> at
> net.sourceforge.stripes.controller.StripesFilter.doFilter(StripesFilter.java:246)
> at
> net.sourceforge.stripes.mock.MockFilterChain.doFilter(MockFilterChain.java:63)
> at
> net.sourceforge.stripes.mock.MockServletContext.acceptRequest(MockServletContext.java:255)
> at
> net.sourceforge.stripes.mock.MockRoundtrip.execute(MockRoundtrip.java:195)
> at
> net.sourceforge.stripes.mock.MockRoundtrip.execute(MockRoundtrip.java:207)
> at
> test.com.upmc.cancercenters.pathways.core.TestPathwayViewer.testViewDiseasePDF(TestPathwayViewer.java:42)
> at
> test.com.upmc.cancercenters.pathways.core.TestPathwayViewer.testBody(TestPathwayViewer.java:27)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59)
> at
> org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98)
> at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79)
> at
> org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87)
> at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77)
> at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42)
> at
> org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88)
> at
> org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
> at
> org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
> at
> org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
> at
> org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
> at
> org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
> at
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
> This doesn't help, the cause of that exception needs to be logged.
> looking at the trunk, I see:
> throw throwable;
> }
> }
> catch (ServletException se) { throw se; }
> catch (IOException ioe) { throw ioe; }
> catch (Throwable t) {
> throw new StripesServletException("Unhandled exception in
> exception handler.", t);
> }
> so it's throwing it inside a try block and catching it.. something isn't
> right here.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://www.stripesframework.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Stripes-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-development
