It doesn't really do that though. Take DisMaxQParser for example, if it can't find a query string through either its given string or through the q.alt param, it throws a SolrException
Sorry ... i was looking at my patched version – agreed it should throw ParseException
At best the QueryComponent catches a ParseException but since it wraps both the parsing of the main query and filter queries into the same try-catch block, it just wraps the ParseException in a SolrException and throws it. Again, no context.
...that can be fixed though, it doesn't cahnge the question of semantics for the QParsers themselves
Here's the patch i put together, the attempted goal was:
1) add javadocs to QParser.parse documenting the (current) expectations
2) automated test verifying that al built-in QParsers meet the expectations when given null or empty string
3) standardizes lucene, dismax, and edismax to treat empty query strings as valid representations of matching nothing
4) fixes all the other special case QParsers to throw a ParseError on null or empty string based on what makes sense (ie: things like TermQParser should allow "" as input, but things like FunctionQParser should not)
...however the test is currently broken, because it doesn't account for the fact that some of the special case QParsers have other required params – it does however nicely demonstrate other ways these Qparsers do a bad job of reporting errors.
Given te level of debate in this issue, and the differences in opinion on what the right / wrong way to address this broader topic of query parsing validation i suggest we punt on this for Solr 3.6 – I'd rather leave things the way they are then make a bad decision in a hurry