ucm run silently fails on exception

[ceedubs]

Create the following function:

main : '{IO, Exception} ()
main _ =
  raise (Failure (typeLink Unit) "blargh" !Any)

From within a ucm session if you run main you will see the following:

  💔💥
  
  The program halted with an unhandled exception:
  
    Failure (typeLink Unit) "blargh" !Any

However, if you issue a non-interactive command ucm run .main it finishes without any output and a 0 exit code (suggesting no failures).

This is tested on release/M2j (built on 2021-10-07) from macos.

---

Acceptance Criteria

• [ ] Calling ucm run .main with a main that triggers an exception should print the exception and fail with a non-zero exit code.

[aryairani]

I think we wanna just do the same output (to stderr if practical) and a nonzero exit code.

[ChrisPenner]

Looked into this and unfortunately the implementations between all of the different run commands are very different from one another.

I tried the most obvious simple fix, but it turns out that using ucm run doesn't have names from the codebase in scope, so you get an error like:

;

Here are the codepaths the different run commands take at the moment:

• .> run .main: creates a "unison file" with the term .main as a watch expression, then gets the runtime to execute the watch expressions in that virtual unison file, then extracts the results for that specific watch expression.
• $ ucm run .main: loads up the codebase then calls evaluateTerm with the term for .main, it doesn't provide any names, nor does it treat anything like watch expressions
• $ ucm run.compiled prog.uc: Loads up the compiled file and passes it to a completely different runtime workflow which executes it, then decompiles and displays the result.
• $ ucm run.file scratch.u .main and $ cat scratch.u | ucm run.pipe .main: Load the codebase, then literally boots up the UCM loop with a single run .main command pre-loaded into the input loop. This gets really weird because ucm still prints all of its messaging and typechecking results (which I guess makes sense in case there's a failure?), but it looks really strange:

IMO having this many different ways to do essentially the same thing is a lot to maintain and is likely to result in confusion both for ourselves and our users, so we may want to take on the effort of unifying them sooner rather than later.

[ceedubs]

The run.compiled command also returns a 0 exit code when terminated via an exception.

[ceedubs]

@ChrisPenner I'm just now noticing your previous message. Are you saying that there's not a straightforward way to change the exit code without also mucking up the output that's printed to stdout (or is it stderr?)? Because I would be fine with the current output if it just returned the expected exit code.

[ChrisPenner]

@ceedubs Unfortunately that message is too old for me to remember so I'll have to guess; but I think we could probably keep the same error message and change the exit code.

I've got a lot on my plate ATM, so not sure when I'll have time to come back around to this, but should be doable.