: I had <mm> (minimum match) blow up at query time with a number : format exception (this is from memory).
That's a RequestHandler specific request param that can also be specified as a default/invarient/appended init param ... i'm not sure that SolrCore could do much to validate that when parsing the solrconfig.xml. DisMaxRequestHandler could possible throw an exception from it's init method if it sees param it recognizes but can't parse ... but that's a dangerous road to go down ... what if i want to subclass DisMaxRequestHandler and change hte format of the "mm" param? One thing you could do to ensure that your RequestHandler configuration makes sense without waiting for an error generated by a request, is to put in some explicit cache warming as part of the firstSearcher listener that hits each configured requestHandler with the minimal amount of input you expect ... then you'll see an error in your log immediately : I had silent a error that I can't remember the details of, but it : was something like putting the <str> for boost functions outside : the <lst>. It didn't blow up, but it was a nonsense config that : was accepted. again, there's nothing erroneous about having a <str> outside of a <lst> when specifing the init params of a RequestHandler as far as SolrCore is concerned ... it has no idea what types of init params the RequestHandler wants ... and the StandardRequestHandler could say that if it sees any top level init params which aren't "defaults", "invarients" or "appended" then it could complain ... but again: what if i subclass StandardRequestHandler and i want to add some custom init param to determine behavior in my subclass? -Hoss
