[ 
https://issues.apache.org/jira/browse/SYSTEMML-611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Deron Eriksson updated SYSTEMML-611:
------------------------------------
    Description: 
Currently, if parsing errors occur, the actual messages are not displayed to 
standard output or standard error except via log4j. As a result, if a user does 
not have log4j configured, they do not see any of the actual parsing error 
messages, which makes it extremely difficult to fix DML/PyDML.

As an example, executing the following code via DMLScript:
{code}
foo();
{code}

generates the following result to the console if log4j is not configured:
{code}
Exception in thread "main" org.apache.sysml.api.DMLException: 
org.apache.sysml.parser.ParseException: One or more errors found during parsing 
(could not construct AST for file: example.dml). Cannot proceed ahead.
        at org.apache.sysml.api.DMLScript.executeScript(DMLScript.java:350)
        at org.apache.sysml.api.DMLScript.main(DMLScript.java:197)
Caused by: org.apache.sysml.parser.ParseException: One or more errors found 
during parsing (could not construct AST for file: example.dml). Cannot proceed 
ahead.
        at 
org.apache.sysml.parser.dml.DMLParserWrapper.parse(DMLParserWrapper.java:98)
        at org.apache.sysml.api.DMLScript.execute(DMLScript.java:588)
        at org.apache.sysml.api.DMLScript.executeScript(DMLScript.java:338)
        ... 1 more
{code}

There are a few issues to address here.
1) A stacktrace such as the one above does not help an end user to write/fix 
DML/PyDML. In fact, it detracts from the important information (the parse error 
message) that the user needs.
2) The actual parsing errors are needed by the end user (not the stacktrace), 
and these should be displayed to standard output/standard error (ie, the 
console) if SystemML is being invoked via DMLScript.
3) The parsing error information should be available at higher levels of the 
call stack (ie, in DMLScript and MLContext, for example). Allowing this 
information to be available at these higher levels has benefits, for example to 
display the parse error information in a notebook via MLContext.




  was:
Currently, if parsing errors occur, the actual messages are not displayed to 
standard output or standard error except via log4j. As a result, if a user does 
not have log4j configured, they do not see any of the actual parsing error 
messages, which makes it extremely difficult to fix DML/PyDML.

As an example, executing the following code via DMLScript:
{code}
foo();
{code}

generates the following result to the console if log4j is not configured:
{code}
Exception in thread "main" org.apache.sysml.api.DMLException: 
org.apache.sysml.parser.ParseException: One or more errors found during parsing 
(could not construct AST for file: example.dml). Cannot proceed ahead.
        at org.apache.sysml.api.DMLScript.executeScript(DMLScript.java:350)
        at org.apache.sysml.api.DMLScript.main(DMLScript.java:197)
Caused by: org.apache.sysml.parser.ParseException: One or more errors found 
during parsing (could not construct AST for file: example.dml). Cannot proceed 
ahead.
        at 
org.apache.sysml.parser.dml.DMLParserWrapper.parse(DMLParserWrapper.java:98)
        at org.apache.sysml.api.DMLScript.execute(DMLScript.java:588)
        at org.apache.sysml.api.DMLScript.executeScript(DMLScript.java:338)
        ... 1 more
{code}

There are a few issues to address here.
1) A stacktrace such as the one above does not help an end user to write/fix 
DML/PyDML. In fact, it detracts from the import information (the parse error 
message) that the user needs.
2) The actual parsing errors are needed by the end user (not the stacktrace), 
and these should be displayed to standard output/standard error (ie, the 
console) if SystemML is being invoked via DMLScript.
3) The parsing error information should be available at higher levels of the 
call stack (ie, in DMLScript and MLContext, for example). Allowing this 
information to be available at these higher levels has benefits, for example to 
display the parse error information in a notebook via MLContext.





> Enhance display of parsing errors for user
> ------------------------------------------
>
>                 Key: SYSTEMML-611
>                 URL: https://issues.apache.org/jira/browse/SYSTEMML-611
>             Project: SystemML
>          Issue Type: Task
>          Components: Parser
>            Reporter: Deron Eriksson
>            Assignee: Deron Eriksson
>
> Currently, if parsing errors occur, the actual messages are not displayed to 
> standard output or standard error except via log4j. As a result, if a user 
> does not have log4j configured, they do not see any of the actual parsing 
> error messages, which makes it extremely difficult to fix DML/PyDML.
> As an example, executing the following code via DMLScript:
> {code}
> foo();
> {code}
> generates the following result to the console if log4j is not configured:
> {code}
> Exception in thread "main" org.apache.sysml.api.DMLException: 
> org.apache.sysml.parser.ParseException: One or more errors found during 
> parsing (could not construct AST for file: example.dml). Cannot proceed ahead.
>       at org.apache.sysml.api.DMLScript.executeScript(DMLScript.java:350)
>       at org.apache.sysml.api.DMLScript.main(DMLScript.java:197)
> Caused by: org.apache.sysml.parser.ParseException: One or more errors found 
> during parsing (could not construct AST for file: example.dml). Cannot 
> proceed ahead.
>       at 
> org.apache.sysml.parser.dml.DMLParserWrapper.parse(DMLParserWrapper.java:98)
>       at org.apache.sysml.api.DMLScript.execute(DMLScript.java:588)
>       at org.apache.sysml.api.DMLScript.executeScript(DMLScript.java:338)
>       ... 1 more
> {code}
> There are a few issues to address here.
> 1) A stacktrace such as the one above does not help an end user to write/fix 
> DML/PyDML. In fact, it detracts from the important information (the parse 
> error message) that the user needs.
> 2) The actual parsing errors are needed by the end user (not the stacktrace), 
> and these should be displayed to standard output/standard error (ie, the 
> console) if SystemML is being invoked via DMLScript.
> 3) The parsing error information should be available at higher levels of the 
> call stack (ie, in DMLScript and MLContext, for example). Allowing this 
> information to be available at these higher levels has benefits, for example 
> to display the parse error information in a notebook via MLContext.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to