I was unfortunately not very clear, and confounded 2 things, an enhanced programmer-facing API, based on yours, for request-handler developers, and secondly an API supported by RequestHandlerBase for request handler configurators.
From the programmer perspective, my contribution is simply to allow specification of either a global error format, and/or a parameter-specific definition of which parameters are required and how missing required parameters should be reported. It has no negative impact on the use case you desire, and the modified code should pass all the exists/doesn't exist tests in your RequiredSolrParamTest.java; if you slapped in your method signatures that return 400 SolrExceptions on bad type conversion, either into my RequiredSolrParams or SolrParams as I suggested above, it should pass all the tests, and if not, I will make it so.
Map<String,String> rmap = new HashMap<String, String>();
rmap.put( "q" , "A query must be specified using the q parameter" );
rmap.put( "version" , "This handler depends on version being explicitly set" );
SolrParams required = new RequiredSolrParams( params, new MapSolrParams( rmap ) );
This is similar to the suggestion in Hoss' first comment on this issue.
The other use-case is for the RequestHandler configurator. There are a lot more of those than RequestHandler programmers. My model is that they are defining request handling service APIs by defining <requestHandler>s in solrconfig. Those APIs can be used by other web programmers in the organization, who will make mistakes in calling the API, as we all do. RequestHandlerBase gives RequestHandler configurators three options for controlling the API, the invariants defaults and appends. I am simply proposing a 4th option to define which parameters are required, and the error message that should be returned in the case it is missing. It's not a comprehensive parameter validation mechanism, but such would be beyond the scope of SOLR. However as someone who is actively creating RequestHandler APIs for other programmers in my organization, using custom code when necessary but avoiding it whenever possible, I think it might be useful.
And in no way does this second use-case by itself allow RH configurators to override the first use-case requirements set up by RH programmers, unless the RH programmers make explicit provision to do so. For example, by chaining a DefaultSolrParams with params derived from a <requestHandler> requires list in front of a default MapSolrParams like the above, the RH programmer allows the RH configurator to add new requirements, and externally change the error strings for programmer-supplied requirements, but not to remove programmer-supplied requirements.
Anyway, hopefully I've better communicated the idea this time.