struts-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Benedict (JIRA)" <j...@apache.org>
Subject [jira] Updated: (STR-2335) Minor changes to ExceptionHandler
Date Tue, 03 Jul 2007 03:22:26 GMT

     [ 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.


Mime
View raw message