Chapel: unhandled error message format

[psahabu]

today

Here is an example of unhandled error messages in Chapel:

unableToOpenFile.chpl:1: error: uncaught error - No such file or directory in open with path "_test_cannotOpenMe.txt"

This has a few deficiencies:

• redundant: error: uncaught error
• uninformative: not clear what type of error was unhandled
• minimal insight: no information beyond where the error was unhandled

A new design is needed to address these issues, but the best way forward is unclear and has many stakeholders.

potential design directions

simple reformatting

There are a few different ways to go here, but here are some ideas:

• remove the leading error:

unableToOpenFile.chpl:1: uncaught error: No such file or directory in open with path "_test_cannotOpenMe.txt"

• include the error type:

unableToOpenFile.chpl:1: uncaught SystemError - No such file or directory in open with path "_test_cannotOpenMe.txt"

stack trace

This opens up a lot of useful possibilities, but that means there's also a lot of possibilities to choose from. Starting from Java's stack trace seems reasonable, here's one possible example:

uncaught SystemError in thread 0 on locale 0:
    at unableToOpenFile.main() [unableToOpenFile:1]
    at [where the error was created]

[mppf]

I'd generally lean towards the stack trace version, even if we only have 2 entries rather than a full stack trace (location error created & location it was not caught). I'm not certain of the value of listing thread and locale numbers there though.

I like the proposals that list the error type (e.g. SystemError).

[lydia-duncan]

I also like noting where the error originally came from. Would that end up being a hidden field/set of fields on the error type, or just something the compiler knows to do?

[mppf]

@lydia-duncan - we'd just store the file name (or int id) and line number in the Error type. I don't think these necessarily need to be hidden fields. I'd expect it to be almost entirely handled in module code.

[bradcray]

Is the stack trace capability redundant with CHPL_UNWIND? (or: does it make CHPL_UNWIND redundant?)

[mppf]

@bradcray - I don't think we're talking right now about implementing full-on stack traces (yet). One day, I think we'd use the CHPL_UNWIND runtime and compiler support to implement the stack traces, in a debug build. CHPL_UNWIND is really about enabling the support for libunwind, and I think we'd still consider using that to do the stack-tracing. (Although, it's certainly the case that we could adjust the emitted code to add "stack frames" to the Error as it propagates. I don't have a good answer for whether or not that would be better. Right now we're just talking about the format of the message.)

[mppf]

Here is my current favorite format:

 uncaught SystemError: No such file or directory in open with path "_test_cannotOpenMe.txt"
   myopen() at unableToOpenFile.chpl:1 (error created)
   main() at unableToOpenFile.chpl:5 (error not caught)

[mppf]

As of today, the consensus direction is to start with something like the current favorite format above. One suggestion to consider is to list the file location first in the stack-trace like section.

[mppf]

I think PR #7119 gets us 95% of the way there, so I'm closing this issue. I hope that future issues about such uncaught error message formatting will refer to this one.