Timeline for Declaring that a function never returns
Current License: CC BY-SA 4.0
22 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 21, 2020 at 21:07 | comment | added | bob | Per the question in question I do want to suggest though: in addition to the frame challenge, it would be helpful to also answer the question. Something like "best practice is really to do X (with explanation) but if you really need to do Y here's how...". Modified that way, this answer would both establish best practice AND help OP if they actually need to do it the way they stated (and any future devs who likewise have the same problem). | |
| Aug 21, 2020 at 20:58 | comment | added | bob | So basically I guess I'm arguing that if we're erring on the side of helping OP, we should answer the question they ask assuming in good faith that if they are breaking best practice they either know what they're doing or they have no other choice. Otherwise I think we wind up acting as an educational site (here's how you should do that instead) rather than a QA site (here's how to do what you asked). | |
| Aug 21, 2020 at 20:54 | comment | added | bob | Right, but we don't know for sure that the actual OP doesn't also need to do it that way. It's hard for us to judge what constraints might apply in OP's situation to make a given best practice more or less suitable, or even off the table. So it seems safer to assume OP knows what they're doing except in extreme circumstances (and of course if they post asking how to commit a crime or do something dangerous, it's definitely worth doing a frame challenge). | |
| Aug 21, 2020 at 20:43 | comment | added | Flater | @bob: Conversely, only posting strict answers on how to do [usually bad practice] without allowing for frame challenges will lead to unintentionally implying that [usually bad practice] is what should be done. There is a difference between answering a general question and answering OP's situation. Often they align, and OPs are incentivized to keep questions generally applicable and reusable for others, but when they don't align, I prioritize the actual OP who posted a question instead of some assumed future reader. | |
| Aug 21, 2020 at 15:56 | review | Low quality posts | |||
| Aug 22, 2020 at 9:44 | |||||
| Aug 21, 2020 at 15:54 | comment | added | bob | This answer is helpful but doesn't answer the question...and is highly-voted...which is quite common unfortunately. The problem with that is if I google a specific problem and come to a SE answer like this one and it does a frame challenge, and despite the best intentions of the frame-challenger I actually do need to do it that way, I am not helped. And that happens fairly often in my experience. In theory theoretical best practices are best practices, but in practice they often aren't. Real projects are beholden to the golden triangle and other immutable constraints. | |
| Aug 20, 2020 at 16:41 | comment | added | supercat | ...without inviting compilers to pretend that computations had magically yielded results which, though incorrect, would allow loops to terminate. | |
| Aug 20, 2020 at 16:36 | comment | added | supercat | @TheHansinator: There are also situations where a function that loops infinitely when unable to compute correct data may be tolerably useless, while returning incorrect data would be intolerably worse than useless. IMHO, instead of giving compilers carte blanche to assume loops will terminate, the Standard should have said that if a piece of code is statically reachable from within a loop, and no individual action within the loop would be sequenced before that piece of code, the loop as a whole isn't sequenced before it either. That would have accommodated most useful optimizations... | |
| Aug 20, 2020 at 14:40 | comment | added | Fred | @JB.WithMonica. Yes, passing a cancellation token would be very interesting to me, however that means the function actually can return (which might not be so bad after all). I am just uncertain in how to declare that the function is going to run forever unless cancelled. | |
| Aug 20, 2020 at 14:19 | comment | added | JB. |
And also provide a way to Cancel / Exit the loop. Might be useful. (see CancellationToken)
|
|
| Aug 20, 2020 at 14:19 | comment | added | Flater | @TheHansinator: You're not accounting for OP's own documentation: "This function never returns. Call it on a new thread." That explicitly argues that this code is intended to run concurrently in a separate thread. Your comment may be valid in some cases but the posted question simply does not confirm to any of the exceptions you're thinking of. | |
| Aug 20, 2020 at 14:15 | comment | added | TheHans255 | 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. | |
| Aug 20, 2020 at 12:36 | comment | added | leftaroundabout | It is encompassed by that, my “not at all true” refered to the premise that this means nobody else would use the code. Anyways, there are also cases where it would not define the application's lifespan. Never-return functions might still raise exceptions or hand on control flow to user-given callbacks. | |
| Aug 20, 2020 at 12:27 | comment | added | leftaroundabout | @Flater not at all true. You may e.g. write a library (or framework) whose purpose it is to allow the consumer to create simple webservers. Most users would use this just as “launch the server now, keep it running until manual terminate or system reboot”, so forking by default would be unnecessary and indeed might lead to confusion “my server always terminates right after I launch it” (precisely because main thread happily keeps running and terminating the program). | |
| Aug 20, 2020 at 12:17 | comment | added | Flater | @leftaroundabout: The only valid use case for a thread-blocking infinite loop is one where it defines the application's lifespan (i.e. always-on services), or self-contained concurrent threads (= which thus can be wrapped, as per my answer). In the former case, there is no code consumer of your class, you are defining your application at the top. OP is asking about people using his code and how to convey its intention, which proves that this code is only one part of a larger codebase, at which point thread-blocking infinite loops are runtime killers, not valid end states for an application. | |
| Aug 20, 2020 at 12:11 | comment | added | leftaroundabout | -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). | |
| Aug 20, 2020 at 5:15 | comment | added | Martin Maat | 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". | |
| Aug 20, 2020 at 1:27 | comment | added | Alexander | 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 | |
| Aug 19, 2020 at 14:22 | comment | added | Flater | @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? | |
| Aug 19, 2020 at 14:17 | comment | added | Fred | I used C# in this example but code in other languages too and I am curious about this issue in other languages too, so the question is indeed language agnostic. Perhaps the play sound example was a poor example, a better one might be a TCP server that listens on a port for incoming connections. You do want to listen for incoming connections forever. Even with async/await, you still have the issue that the consumer doesn't know if he should await it on the same thread or run it on a new thread. | |
| Aug 19, 2020 at 14:11 | history | edited | Flater | CC BY-SA 4.0 |
added 227 characters in body
|
| Aug 19, 2020 at 14:05 | history | answered | Flater | CC BY-SA 4.0 |