Why does Spring wrap RuntimeException in NestedServletException when handle endpoint exception?

Question

According to Servlet Specification:

A servlet or filter may throw the following exceptions during processing of a request:

1. runtime exceptions or errors
2. ServletExceptions or subclasses thereof
3. IOExceptions or subclasses thereof

If we look at org.springframework.web.servlet.FrameworkServlet#processRequest, we'll see that Spring throws ServletException and IOException, but wraps others including RuntimeExceptions:

try {
    doService(request, response);
} catch (ServletException | IOException ex) {
    failureCause = ex;
    throw ex;
} catch (Throwable ex) {
    failureCause = ex;
    throw new NestedServletException("Request processing failed", ex);
}

Why doesn't Spring handle RuntimeException like IOException?

UPD: In other words, what wrong would happen if they handle exceptions this way:

try {
    doService(request, response);
} catch (ServletException | IOException | RuntimeException ex) {
    failureCause = ex;
    throw ex;
} catch (Throwable ex) {
    failureCause = ex;
    throw new NestedServletException("Request processing failed", ex);
}

Answer 1

This is required because the protected abstract doService method invoked inside processRequest can throw any checked or unchecked Exception.

protected abstract void doService(HttpServletRequest request, HttpServletResponse response) throws Exception;

Now, imagine that you override doService like:

@Override
protected void doService(Long request, Long response) throws ClassNotFoundException {
// whatever ...
}

This would be perfectly legitimate but then processRequest will be potentially throwing a ClassNotFoundException which you will have to declare as a checked exception. And because processRequest is used by doGet, doPost and the other API methods, these will have to declare ClassNotFoundException as well, breaking the specification.

Note that this applies mostly to the case when doService is not the implementation provided by org.springframework.web.servlet.DispatcherServlet. doService in DispatcherServlet calls doDispatch and doDispatch already catches everything but ServletException or IOException. However, there is still the need of catching the exceptions again because the declaration of doService and doDispatch do not restrict the list of their checked exceptions to ServletException and IOException.

Edit 21/11/2019:

I do not see any trouble in your alternative exception handling convention. Indeed is closer to the spec interpreted literally. The implementation is just wrapping everything which is not a ServletException or IOException. It might be because later a handler is sensitive to the exception type. But this is not the case at least for the DefaultHandlerExceptionResolver used by the DispatcherServlet.

I can't see neither any obvious problem which could affect error handling in web.xml with <error-page><exception-type>...</exception-type></error-page> or using a @Component implementing ErrorPageRegistrar.