[ https://issues.apache.org/struts/browse/STR-2335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Benedict updated STR-2335:
-------------------------------
Fix Version/s: 1.4.0
Assignee: (was: Struts Developers)
I am pretty sure the new ComposableRequestProcessor allows RuntimeException to be propagated
to the ExceptionHandler. I am assigning this to 1.4.0 so I can verify.
> Minor changes to ExceptionHandler
> ---------------------------------
>
> Key: STR-2335
> URL: https://issues.apache.org/struts/browse/STR-2335
> Project: Struts 1
> Issue Type: Improvement
> Components: Core
> Affects Versions: 1.2.4
> Environment: Operating System: All
> Platform: All
> Reporter: Willis Boyce
> Priority: Minor
> Fix For: 1.4.0
>
>
> I'm finding the ExceptionHandler class to be frustrating for two reasons.
> 1. ExceptionHandler does not allow IOException to propagate to the
> container. It effectively filters out IOException.
> What I'm specifically trying to do in this case is write an ExceptionHandler
> subclass that invokes HttpServletRequest.sendError, which throws an
> IOException. The current implementation of ExceptionHandler forces me to wrap
> the IOException in a ServletException or a RuntimeException.
> I think that it's useful to think of ExceptionHandler as an adapter between
> Action.execute, which can throw anything, and Servlet.service, which can only
> throw ServletException and IOException. Changing ExceptionHandler.execute to
> throw both ServletException and IOException would allow ExceptionHandler to be
> used in this manner. In addition, the try block in
> RequestProcessor.processException could be eliminated entirely. (It's kind of
> strange as is, since it takes any Exception and wraps it in a
> ServletException, even though ExceptionHandler.execute can only throw
> ServletException in the first place.)
> 2. ExceptionHandler logs every unhandled exception as a warning. This
> includes IOException, which may be thrown for entirely legitimate reasons and
> hardly ever needs to be explicitly handled. If I want to let the servlet
> container handle exceptions, then I'm guaranteed to get all sorts of spurious
> warnings about "unhandled" exceptions from Struts even though I'm handling
> them perfectly well elsewhere. Struts shouldn't presume to know everything
> about the application's exception handling strategy. Maybe a boolean could be
> added to the Struts configuration that would cause Struts to be silent
> about "unhandled" exceptions.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
|