slinkydeveloper commented on a change in pull request #18363:
URL: https://github.com/apache/flink/pull/18363#discussion_r807884744



##########
File path: 
flink-table/flink-table-planner/src/main/java/org/apache/flink/table/planner/parse/CalciteParser.java
##########
@@ -47,12 +49,36 @@ public CalciteParser(SqlParser.Config config) {
      * @param sql a sql string to parse
      * @return a parsed sql node
      * @throws SqlParserException if an exception is thrown when parsing the 
statement
+     * @throws SqlParserEOFException if the statement is incomplete
      */
     public SqlNode parse(String sql) {
         try {
             SqlParser parser = SqlParser.create(sql, config);
             return parser.parseStmt();
         } catch (SqlParseException e) {
+            if (e.getMessage().contains("Encountered \"<EOF>\"")) {
+                throw new SqlParserEOFException(e.getMessage(), e);
+            }
+            throw new SqlParserException("SQL parse failed. " + 
e.getMessage(), e);
+        }
+    }
+
+    /**
+     * Parses a SQL string into a {@link SqlNodeList}. The {@link SqlNodeList} 
is not yet validated.
+     *
+     * @param sql a sql string to parse
+     * @return a parsed sql node list
+     * @throws SqlParserException if an exception is thrown when parsing the 
statement
+     * @throws SqlParserEOFException if the statement is incomplete
+     */
+    public SqlNodeList parseSqlList(String sql) {
+        try {
+            SqlParser parser = SqlParser.create(sql, config);
+            return parser.parseStmtList();
+        } catch (SqlParseException e) {
+            if (e.getMessage().contains("Encountered \"<EOF>\"")) {
+                throw new SqlParserEOFException(e.getMessage(), e);

Review comment:
       That's personal preference and it's not a blocking issue for me. But i 
can see how we might want in future to catch other parsing errors (also see in 
context of 
https://cwiki.apache.org/confluence/display/FLINK/FLIP-189%3A+SQL+Client+Usability+Improvements)
 and one class per error type is overkill and it's going to explode. The point 
is that if what you need is just to match the specific error type variant, but 
the variants themselves don't have any other useful error data, then you don't 
subclasses. 




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


Reply via email to