I think it's because CoreContainer.create() is catching Exceptions, not Errors, when updating the coreInitFailure map.
Sure - but the piece i couldn't make sense of is why/where testJavaLangErrorFromHandlerOnStartup passed (and those Errors ere in coreInitFailures) but testJavaLangErrorFromSchemaOnStartup didn't.
digging arround a bit more, it looks like this is because SolrCore() is wrapping some types of Throwable in SolrException (shudder) but the IndexSchema already exists before the SolreCore constructor is called, and any Errors that come from it don't get similar wrapping.
Maybe the best solution is for SolrResourceLoader to try and catch LinkageErrors and rethrow it as a SolrException. Catching classloader problems is I think within the resource loader's remit (unlike out of memory errors, etc).
maybe - but that's a slippery slope i'd rather avoid – i'm catching & re-throwing Errors is one thing, wrapping Errors in Exceptions is something i'm very much not a fan of.
i think a safer (and more all encompasing) fix would be for CoreContainer to handle wraping Errors in SolrException - not for the purpose of re-throwing, but just for tracking in coreInitFailures. that way even for things like OOM or IOError during core init, we still have a note about it in coreInitFailures.
Attaching an updated patch that goes this direction - still running tests, but review/comments appreciated