Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

>You think X might loop 100x? Put a limit of 10,000 ("absurd and impossible")...

This feels like a lot of line noise for those rare-until-you-hit-them bugs. Just capping a loop with a fixed iteration size deserves a comment as to the rationale. Do you do it everywhere? Just IO?

The idea has merit, but in practice, I am not sure where I would implement it. Plus, there would always be the temptation to remove that do-nothing code.



If it's much "do nothing" code to remove, perhaps it'd be better to move to a more expressive language. E.g. for Ruby at least, block arguments means it's trivial to do this:

    def at_most(num)
       num.times {  yield }
       raise "Should never get here" # or "binding.irb"/"binding.pry" to drop you into a repl, perhaps contingent on a command line flag.
    end

 and do:

     at_most(5) do
        .. logic
     end
If the number isn't obviously absurdly high, I agree it'd be worth documenting why the precise number was chosen, but then it might be worth documenting why as an indication of why you thought an infinite loop was appropriate anyway.


Yep. In essentially every language there's a reasonably efficient way to do it in one or two lines at most.

It's really not much noise, and it serves as (mechanically checked!) documentation of the expected size of a loop. In some ways that's an improvement, since it's just a loopy assert.


> Plus, there would always be the temptation to remove that do-nothing code.

It's not 'do-nothing' code, though. Isn't the temptation just the same as the temptation to remove 'do-nothing' exception handling or 'do-nothing' unit tests?


> This feels like a lot of line noise for those rare-until-you-hit-them bugs.

Yeah, but if doing so can eliminate an entire class of bugs...

...you know something? I think I'm starting to see where those Rust guys are coming from.


As a counter-argument: why are we generally ok with allowing things to be infinite when they're expected to be finite? Precise bounds are obviously best, but sometimes it's not efficiently calculable or not worth the effort - don't choose the literal worst possible value there (infinity), pick something that'll stop itself when it goes insane.

And no, it's a tool. Use it where it makes sense.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: