Skip to content

Improve the semantics of try_for

To make try_for accept a “try” it wants the block to return something that can be interpreted as true (essentially anything but nil and false) which makes sense in some cases, mostly when what we are trying is to run a single command in the block, that returns a boolean value. However, quite often we’re doing multiple things, and something that will lead to weird situations. For instance:

try_for(10) do
  check_that_throws_exception_on_failure_1
  check_that_throws_exception_on_failure_2 if check_that_returns_boolean_and_never_throws_an_exception
end

If check_that_returns_boolean_and_never_throws_an_exception is false, the last line in the block will evaluate to nil, so try_for always fails. That doesn’t make sense. We’d have to fix it with something ugly like:

try_for(10) do
  check_that_throws_exception_on_failure_1
  check_that_throws_exception_on_failure_2 if check_that_returns_boolean_and_never_throws_an_exception
  true
end

I think it’d be better if try_for simply runs the block without checking the return value, so that the only way a “try” fails is if there’s an exceptions raised. In the instances where we run something like:

try_for(10) { check_that_returns_boolean_and_never_throws_an_exception }

we then instead do:

try_for(10) { assert(check_that_returns_boolean_and_never_throws_an_exception) }

which imho is even clearer.

Parent Task: #10237

Original created by @anonym on 9223 (Redmine)

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information