Graceful error handling in daml repl
#4673
Conversation
This PR changes `daml repl` to handle errors (parse errors, type errors, unsupported statement errors, script errors) gracefully and just emit an error message instead of tearing down the whole process. This gets the repl into a state where I think it’s sufficiently user-friendly to be released (obviously there are tons of potential improvements). The only thing missing before I’m comfortable mentioning this in release notes and uninternalizing it are docs. If you think there is something crucial that needs to be addressed before, let me know. changelog_begin changelog_end
| , matchOutput "^.*: 1" | ||
| ] | ||
| , testInteraction' "type error" | ||
| [ input "1" |
There was a problem hiding this comment.
I think it would be more intuitive if a raw, pure expression did not result in a type error, but instead caused a debug to be inserted automatically, turning it into a Script _ expression. I think we should try to reserve "type errors" in the repl for non-pure expressions (e.g. tried to use Update monad instead of Script monad), or for pure expressions that have type errors in them (e.g. passed an argument of the wrong type). This is way more work than should be in this PR, though.
There was a problem hiding this comment.
(As for how to implement that, we could catch type errors with "expected Script", add a debug, and try again. Maybe that's kinda messy, but I think it would make the interface more accessible.)
There was a problem hiding this comment.
I fully agree that this would be a nicer UX! GHCi also prints the result if you have something of type IO a where a is an instance of Show (and not ()) which would be nice to have. It also has some magic defaulting to IOwhich makes things likepure 1work automagically (that’s the main reason why I currently have the type annotation toScript _`. Not sure how much more clever that is than typechecking twice and if it’s possible to adapt this for our usecase.
This PR changes
daml replto handle errors (parse errors, typeerrors, unsupported statement errors, script errors) gracefully
and just emit an error message instead of tearing down the whole
process.
This gets the repl into a state where I think it’s sufficiently
user-friendly to be released (obviously there are tons of potential
improvements). The only thing missing before I’m comfortable
mentioning this in release notes and uninternalizing it are docs.
If you think there is something crucial that needs to be addressed
before, let me know.
changelog_begin
changelog_end
Pull Request Checklist
CHANGELOG_BEGINandCHANGELOG_ENDtagsNOTE: CI is not automatically run on non-members pull-requests for security
reasons. The reviewer will have to comment with
/AzurePipelines runtotrigger the build.