stanfordnlp/CoreNLP · error · ParseException

Relation not handled by getRelation

Error message

Relation  not handled by getRelation

What it means

This ParseException is the default branch of the first GraphRelation.getRelation overload (String reln, String type, String name, String edgeName). It fires when the relation string passed isKnownRelation() (so it is a recognized Semgrex operator) but the switch statement finds no construction branch for it and edgeName is null. This is effectively an internal fall-through: a known relation reached the default case, meaning it was not matched by either switch in the method.

Solutions

  1. Verify the relation string is one handled by this overload; for numeric-limited relations use the (reln, type, int num, ...) overload instead.
  2. If you modified isKnownRelation(), add a matching case to getRelation's switch or route it before the switch.
  3. Update to a consistent CoreNLP version so isKnownRelation and getRelation agree.
  4. Wrap pattern compilation in try-catch for ParseException and report the raw pattern to identify the offending operator.

Example fix

// before (custom relation added only to isKnownRelation)
isKnownRelation: ... || reln.equals(">>") ...
// after: also add a construction branch
case ">>": return new GRANDPARENT(type, name);
Defensive patterns

Strategy: try-catch

Validate before calling

if (!GraphRelation.isKnownRelation(reln)) {
  throw new IllegalArgumentException("Unknown relation: " + reln);
}

Try / catch

try {
  GraphRelation r = GraphRelation.getRelation(reln, type, name, edgeName);
} catch (ParseException e) {
  log.severe("Unhandled relation '" + reln + "' in pattern; check CoreNLP version consistency");
}

Prevention

When it happens

Trigger: Calling getRelation(reln, type, name, edgeName) with edgeName == null and a relation from isKnownRelation() that is not matched by either switch, e.g. due to a custom relation added to isKnownRelation() without a corresponding case in getRelation, or an inconsistent build where the two dispatch tables disagree.

Common situations: Custom forks or modified Stanford CoreNLP builds where isKnownRelation() was extended without updating getRelation's switch; library upgrades where new operators exist in isKnownRelation but the dispatch was not synchronized; defensive code paths reached during pattern deserialization.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

AI-assisted analysis of stanfordnlp/CoreNLP@1b7edd19c4 (2026-09-10). Data as JSON: /api/errors/39dfdf18654d8dd5. Report an issue: GitHub.

Appendix: source

Thrown at src/edu/stanford/nlp/semgraph/semgrex/GraphRelation.java:1508

      case "$-":
        return new LEFT_IMMEDIATE_SIBLING(type, name);
      case "$++":
        return new RIGHT_SIBLING(type, name);
      case "$--":
        return new LEFT_SIBLING(type, name);
      case ".":
        return new ADJACENT_RIGHT(type, name);
      case "..":
        return new RIGHT(type, name);
      case "-":
        return new ADJACENT_LEFT(type, name);
      case "--":
        return new LEFT(type, name);
      case "@":
        return new ALIGNMENT();
      default:
        //error
        throw new ParseException("Relation " + reln +
            " not handled by getRelation");
    }
  }

  public static GraphRelation getRelation(String reln,
                                          String type,
                                          int num,
                                          String name,
                                          String edgeName) throws ParseException {
    if (edgeName != null) {
      throw new ParseException("Relation " + reln + " does not allow for named edges");
    }
    if (reln == null && type == null)
      return null;
    if (reln.equals(">>"))
      return new LIMITED_GRANDPARENT(type, name, num, num);
    else if (reln.equals("<<"))
      return new LIMITED_GRANDKID(type, name, num, num);

View on GitHub (pinned to 1b7edd19c4)