Error Reporting

This is a guide for rascal developers on how to report errors to the user.

There are only 2 kinds of errors:

1. errors the user should see
2. errors only a rascal developer should see

Definitions

• User: develops in rascal using the plugin.
• Developer: develops in java to extend rascal.

Error reporting to a user

• Write to the evaluator.getStdErr() stream. Getting a reference to the evaluator is often just a . away. Either use println, printf, or format to trigger the auto flushing, or manually flush the stream after you report an error.
• Throw a rascal exception throw new Throw() Make sure you are not the highest method in the chain (IDE contributions, visualisation framework, or the shell itself)

What will happen with the error?

• Function called from console: the error will print in the console
• Function called as a callback (vis-framework, ide-contributions): the error will always print in the output window

Error reporting to the developer

Always send the exception to Activator.log(msg, exception), (no need for the .getInstance() call). Or if you are just debugging, send it to System.err.

What will happen with the error?

It will be reported to the errors view, which is not part of the default rascal perspective. So never report an error to this if the user might be interested in the fact that the code failed.

Note: we do not have a good story yet for users of the user. But since we split the messages between the stdOut and stdErr, there might be a clean solution for this.