Moritz Kiefer d83387a64d Improve error messages in daml repl on calls to error (#5565) ... * Improve error messages in daml repl on calls to `error` There were two issues with calls to `error`: 1. This one is harmless but somewhat annoying: When calling `error` we run into the log statement in `stepToValue` which prints out the error message in a fairly reasonable form (you can argue whether Error: User abort: is a super useful prefix but that’s a relatively minor issue). Afterwards we then call `println` on the failed future. However, that will just print the type of the exception which isn’t something we want to show to users. I’ve just disabled the println statement if the exception is `SError`. 2. This one is a bigger issue: `throw x` is not the same as `Future.failed(x)`. I only fully realized the difference fairly recently. The former fails before it produces a future. So `(throw x).onComplete(…)` will never execute the callback. The latter is just a failed future. It is rather confusing to have a function that returns a future but then throws an exception instead of a future and it confuses the grpc library which prints out a horrible exception. I’ve changed all calls to `throw` in `runWithClients` to instead use `Future.failed` and `flatMap` (in the form of for-comprehensions). There are still a few calls in `run` left which I’ll leave for a separate PR. I think we need to factor out some helper functions here to make this a bit more manageable (e.g. for the Converter.toFuture) stuff but I’ll leave that for a separate PR. You probably want to view this with whitespace diffs disabled. changelog_begin - [DAML Repl] DAML Repl now produces better error messages on calls to `error` and `abort`. changelog_end * Switch stepToValue to return Either		2020-04-15 16:19:36 +00:00
..
src/main	Improve error messages in daml repl on calls to error (#5565)	2020-04-15 16:19:36 +00:00
BUILD.bazel	Use com.daml as root package (#5343)	2020-04-05 19:49:57 +02:00