antlr/antlr4 · warning · ArgumentException

Could not read path: ${path}

Error message

Could not read path: ${path}

What it means

XPath.Split wraps an IOException raised while creating the AntlrInputStream over the path string and rethrows it as ArgumentException. In the C# port the input is a StringReader over an in-memory string, so this exception path is effectively unreachable in practice — but it is kept for Java parity. Seeing it means reader construction threw unexpectedly (custom environment/stream issue).

Source

Thrown at runtime/CSharp/src/Tree/Xpath/XPath.cs:100

            // word not operator/separator
            // word for invert operator
            this.parser = parser;
            this.path = path;
            elements = Split(path);
        }

        //		System.out.println(Arrays.toString(elements));
        // TODO: check for invalid token/rule names, bad syntax
        public virtual XPathElement[] Split(string path)
        {
            AntlrInputStream @in;
            try
            {
                @in = new AntlrInputStream(new StringReader(path));
            }
            catch (IOException ioe)
            {
                throw new ArgumentException("Could not read path: " + path, ioe);
            }
            XPathLexer lexer = new _XPathLexer_87(@in);
            lexer.RemoveErrorListeners();
            lexer.AddErrorListener(new XPathLexerErrorListener());
            CommonTokenStream tokenStream = new CommonTokenStream(lexer);
            try
            {
                tokenStream.Fill();
            }
            catch (LexerNoViableAltException e)
            {
                int pos = lexer.Column;
                string msg = "Invalid tokens or characters at index " + pos + " in path '" + path + "'";
                throw new ArgumentException(msg, e);
            }
            IList<IToken> tokens = tokenStream.GetTokens();
            //		System.out.println("path="+path+"=>"+tokens);
            IList<XPathElement> elements = new List<XPathElement>();

View on GitHub (pinned to 7d5770395b)

Solutions

  1. Treat this as an environment anomaly: check the path string for correctness and retry with a plain literal XPath.
  2. If you maintain a custom port where the input comes from a file/stream, move to a real file-reading step with its own error handling before constructing XPath.
  3. Report to the runtime maintainers if reproducible, since the stock StringReader path cannot throw.
Defensive patterns

Strategy: try-catch

Validate before calling

if (path == null) throw new ArgumentNullException(nameof(path)); // path itself must be sane; the IOException branch is otherwise unreachable in the C# port

Try / catch

try { var xp = new XPath(parser, path); } catch (ArgumentException ex) when (ex.Message.StartsWith("Could not read path")) { /* environment anomaly: log path and inner IOException, retry with a literal */ }

Prevention

When it happens

Trigger: Constructing new XPath(parser, path) where the internal StringReader over the path string throws IOException — theoretically only from exotic runtime failures; in normal C# usage never thrown.

Common situations: Essentially none in the C# runtime; would only surface if the runtime violates StringReader's contract or a modified port reads from a real I/O source.

Related errors


AI-assisted analysis of antlr/antlr4@7d5770395b (2026-08-14). Data as JSON: /api/errors/e33e7cdcc78564a9. Report an issue: GitHub.