stanfordnlp/CoreNLP · error · IllegalStateException
Someone didn't add a handler for a new docType.
Error message
Someone didn't add a handler for a new docType.
What it means
DocumentPreprocessor.iterator() dispatches on the DocType enum; only Plain and XML have implemented iterators. If docType holds any other value, the library throws this IllegalStateException because a new DocType was added without a corresponding iterator handler. In normal use this means the DocType passed to the constructor is not supported by this code path.
Solutions
- Use DocType.Plain for regular text or DocType.XML for XML documents
- Check for a version mismatch between library jars and switch to a consistent CoreNLP version
- If you added a custom DocType, implement and return a matching Iterator in iterator()'s dispatch chain
- Validate the DocType right after construction (fail early) rather than at iteration time
Example fix
// before DocumentPreprocessor dp = new DocumentPreprocessor(reader, DocType.Media); // after DocumentPreprocessor dp = new DocumentPreprocessor(reader, DocType.Plain); // supported type
Defensive patterns
Strategy: validation
Validate before calling
if (docType != DocType.Plain && docType != DocType.XML) {
throw new IllegalArgumentException("Unsupported DocType for DocumentPreprocessor: " + docType);
} Try / catch
try (Iterable<List<HasWord>> sents = () -> dp.iterator()) {
// consume sentences
} catch (IllegalStateException e) {
if (e.getMessage() != null && e.getMessage().contains("didn't add a handler")) {
throw new UnsupportedDocTypeException(docType, e);
}
throw e;
} Prevention
- Restrict DocType usage to Plain and XML in your code
- Pin all CoreNLP jars to one version to avoid enum/implementation mismatches
- Assert the DocType immediately after construction rather than at iteration time
When it happens
Trigger: Constructing a DocumentPreprocessor with a DocType other than Plain or XML (e.g. a custom/newer DocType constant) and then iterating via iterator(), tokens(), or a for-each over the preprocessor.
Common situations: Using a DocumentPreprocessor subclass or an upgraded enum from a newer CoreNLP version with an older iterator implementation; copy-pasted construction code setting an exotic DocType; reflection-based instantiation choosing the wrong enum constant.
Related errors
- Unhandled case: " + mono + " and " + type
- Unknown mode + mode
- Unknown model type " + modelType
- Arabic does not support feature type: " + feat.toString()
- Attempt to use ExternalFiniteDifference without passing…
AI-assisted analysis of stanfordnlp/CoreNLP@1b7edd19c4 (2026-09-10).
Data as JSON: /api/errors/be701a40e44ed272.
Report an issue: GitHub.
Appendix: source
Thrown at src/edu/stanford/nlp/process/DocumentPreprocessor.java:231
/**
* Returns sentences until the document is exhausted. Calls close() if the end of the document
* is reached. Otherwise, the user is required to close the stream.
*
* @return An Iterator over sentences (each a List of word tokens).
* Although the type is given as {@code List<HasWord>}, in practice you get a List of CoreLabel,
* and you can cast down to that. (Someday we might manage to fix the generic typing....)
*/
@Override
public Iterator<List<HasWord>> iterator() {
// Add new document types here
if (docType == DocType.Plain) {
return new PlainTextIterator();
} else if (docType == DocType.XML) {
return new XMLIterator();
} else {
throw new IllegalStateException("Someone didn't add a handler for a new docType.");
}
}
private class PlainTextIterator implements Iterator<List<HasWord>> {
private final Tokenizer<? extends HasWord> tokenizer;
private final Set<String> sentDelims;
private final Set<String> delimFollowers;
private final Function<String, String[]> splitTag;
private List<HasWord> nextSent; // = null;
private final List<HasWord> nextSentCarryover = Generics.newArrayList();
public PlainTextIterator() {
// Establish how to find sentence boundaries
boolean eolIsSignificant = false;
sentDelims = Generics.newHashSet();
if (sentenceDelimiter == null) {View on GitHub (pinned to 1b7edd19c4)