I dont like it being LuceneAnalysisException really: I don't see the need for a custom class.
I think it would just be throw new IllegalArgumentException("exception from analysis chain for field '" + field + "':", fieldName, originalException).
I think it makes life better, as I don't see much evil in exception wrapping like this.
There is a lot of evil still, it changes the class type of the exception (by wrapping it), by nesting, it makes exceptions harder to digest for the client (lots of lucene users use the same Analyzer for every field, so the field is just not interesting).
Remember this is all about the buggy analyzer case. Its not like we are supporting a real use case here.
So that's why i said, i'm not sure about this whole idea on
SOLR-5623. I'm just not sure its the right tradeoffs.
Besides, there are possibly even less invasive solutions. If we hit an exception from the analyzer, we could write that we hit an exception (not the exception text, just that we hit one) for field X to the infostream in the if (Unable to render embedded object: File (success) case. This means there is no catch block at all) not found. I would support such a change today. sure its not "perfectly user friendly" but it has absolutely no downsides at all, and only helps the user, and remember, this is all about the buggy analyzer case. We don't need to be user friendly for that, just safe.