Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • T tails
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 931
    • Issues 931
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 18
    • Merge requests 18
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • tails
  • tails
  • Issues
  • #9223

Closed
Open
Created Apr 10, 2015 by anonym@anonymMaintainer

Improve the semantics of try_for

Originally created by @anonym on #9223 (Redmine)

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 (closed)

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