Stream: ideas

Topic: allow try in expect

Oskar Hahn (Dec 02 2024 at 08:21):

Currently, try is only allowed, if the function returns an Result.

It would be nice, if try would also be allowed in an expect block.

When you test a function, that can fail, you currently have to test it like this:

expect
  got = funcThatCanFail
  expected = Ok ExpectedValue
  got == expected

It would be nice, if this would be supported:

expect
  got = funcThatCanFail |> try
  expected = ExpectedValue
  got == expected

A failed expect could produce a more precise error message, if the block produces an Err.

The message would also be nicer, when the function returns an Ok but with a wrong payload. Currently the message is like:

got : Result Str [BadUtf8 Utf8ByteProblem U64]
got = Ok "wrong value"

expected : [
    Err [BadUtf8 Utf8ByteProblem U64],
    Ok Str,
]
expected = Ok "right value"

With that proposal, the message would look like:

got : Str
got = "wrong value"

expected : Str
expected = "right value"

Sam Mohr (Dec 02 2024 at 08:27):

I totally agree, I proposed the same thing a month or two ago and the team seemed to like it. It was a bit of a different form... let me find it

Sam Mohr (Dec 02 2024 at 08:28):

https://roc.zulipchat.com/#narrow/channel/304641-ideas/topic/top.20level.20.3F.20try/near/472984263

Oskar Hahn (Dec 02 2024 at 08:31):

Yes. This sounds like the same idea.

Is there already an issue for it? Should I create one?

Sam Mohr (Dec 02 2024 at 08:31):

Yeah, please create an issue! I don't believe one exists yet

Sam Mohr (Dec 02 2024 at 08:32):

Just to make sure, though, I think the easiest way to implement this would be to allow expects to have a block that either:

• Doesn't use try and returns Bool
• Might use try and returns Result Bool err where err implements Inspect

Sam Mohr (Dec 02 2024 at 08:33):

Meaning the last statement would have to be Ok (x == y)

Sam Mohr (Dec 02 2024 at 08:34):

Which isn't quite as clean, but if we try to support try and a Bool final expr, then I think we'll have to do some weird type wiring just for expects that doesn't apply to normal blocks, but maybe I'm mistaken

Oskar Hahn (Dec 02 2024 at 09:00):

I understand what you mean. But from a user perspective the requirement to write Ok (x == y) is weird.

Would it be possible, that a try in an expect block works more like Result.map?

expect
  funcThatCanFail |> Result.map \got ->
      expected = ExpectedValue
      got == expected

(or with backpassing syntax)

expect
  got <- funcThatCanFail |> Result.map
  expected = ExpectedValue
  got == expected

Sam Mohr (Dec 02 2024 at 09:06):

What if there are multiple try statements?

Oskar Hahn (Dec 02 2024 at 09:09):

You are right. Could it be, that what I actually want is a shorthand syntax for Result.map?

Maybe, I should not be so greedy and go for the Ok (x == y) :sweat_smile:

Sam Mohr (Dec 02 2024 at 09:15):

Yeah...

Sam Mohr (Dec 02 2024 at 09:17):

We could try something like try working differently in expect. It now functions as:

when result is
    Ok ok -> ok
    Err err -> crash "result failed with Err $(Inspect.toStr err)"

Sam Mohr (Dec 02 2024 at 09:17):

This would still make type checking and all complicated, but manageable

Last updated: Jun 16 2026 at 16:19 UTC