Skip to main content
Software Engineering

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

19
  • 13
    @Fred: If you presume that the infinite loop is warranted here (which I'm willing to believe you on), it's better to prevent people getting stuck on it (by writing your own thread-spawning logic around it and having your consumers use that) instead of trying to decide on the phrasing used on the warning signs (= wondering how to clearly document it). Your question is built on the idea that you can just push the effort of safely handling your class onto the consumer, but I disagree and feel that you should make things safe yourself. You expect your car to come with seat belts and airbags, no?
    – Flater
    Commented Aug 19, 2020 at 14:22
  • 9
    On the flip side, there are so many different threading mechanisms in some languages, it might not be appropriate to "force" the choice of a particular one. I see value in having both: have a convenience method that spawns the thread/queue/channel or whatever else is appropriate in your language, have it call another method does the loop and never returns, but make that method also public in case people have other uses for it. Alternatively, make your method only do one "iteration", and have the use control it themselves. See also: developer.apple.com/documentation/foundation/runloop
    – Alexander
    Commented Aug 20, 2020 at 1:27
  • 5
    What strikes me the most as bad here is that he is making decisions for the application programmer. No doubt with the intent to be helpful but this isn't helpful. If the API user wants to play the sound repeatedly or do whatever repeatedly, he can do so in whatever way he sees fit. I would be cursing an API as described. "What was this idiot thinking? This is utterly useless".
    – Martin Maat
    Commented Aug 20, 2020 at 5:15
  • 11
    -1 from me. Your comment about concurrency is absolutely valid, but it's quite orthogonal to the question. Indeed, an explicit never-return type is quite a good way of indicating to somebody using such a library function that it may be a good idea to wrap this call in a thread fork, without forcing them to use concurrency (which might be counterproductive overkill for something really running indefinitely on an embedded device with scarce resources).
    – leftaroundabout
    Commented Aug 20, 2020 at 12:11
  • 6
    There are some situations, such as in systems programming, where you absolutely do need an infinite loop or a function that otherwise never returns, and absolutely do need to call it without spinning off a thread. This includes, for instance, the Rust panic handler, which is defined when there isn't a standard library, called when the app panics, and is expected to take over the process. Calls like exit() are declared as never returning for a similar reason.
    – TheHans255
    Commented Aug 20, 2020 at 14:15