https://bz.apache.org/bugzilla/show_bug.cgi?id=58323
benjamin.gehrels_exter...@immobilienscout24.de changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|INVALID |---
--- Comment #2 from benjamin.gehrels_exter...@immobilienscout24.de ---
I am not quite sure about that. I would say, if it would be critical, it would
have been the Servlets responsibility to have done a
try-catch-log-rethrowAsServletException. If it failed to do so, its worth maybe
a warn, but not an error.
We had that discussion on the Spring MVC Jira
(https://jira.spring.io/browse/SPR-12745 ) and after reading the comments
there, i am not quite sure if the Servlet is even allowed to "catch and handle
such errors appropriately" (that is, swallow) that Exception.
One could argue that the container (that manages and owns the connection)
somehow "borrows" it to the servlet (via the ServletRequests/Responses
Input/Output streams). The IOException thrown by the Servlet is then a way to
tell the container "Hey, i borrowed your connection, but something broke and
now i am not sure if i return it in an non-broken state. Be aware that it may
be fishy somehow".
The fact that the servlet spec explicitly includes it ("throws
java.io.IOException - if an input or output exception occurs") in the interface
somehow suggests that. Otherwise, it could have simply forced us to wrap the
IOException in a ServletException or Runtime exception - like all the other
non-IO Exceptions. In the end, only the container knows what to do with its
broken connection.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
