Skip to main content
14 events
when toggle format what by license comment
Jul 28, 2023 at 7:34 comment added NeilG It's facile to argue that catching Exception is bad because you should always be catching specific exception types anyway. You only catch Exception when you know you want to catch everything. You can create a custom sub-class of Exception for flow control if you want to and then only catch that sub-class: presto! No need to worry about catching built-in exceptions accidentally! Now that wasn't so hard, was it?
Jun 5, 2023 at 0:59 comment added wtr @RayLuo, the original question is "Are exceptions for flow control best practice in Python?" and when an answer says "NO!" with no supporting arguments, it's a bit disappointing. My downvote wasn't because I thought the answer should be a yes, it was because I wanted to hear the "why" behind the no. I agree with you that my statement was "emphatic," and intentionally so; I was trying to "emphasize" a particular aspect, after all! ;)
Jun 5, 2023 at 0:40 comment added wtr @SteveBarnes Wow! I'm impressed <3 Upvoted, and thank you for updating! Side note: I'm glad I was vocal about my reasoning for downvoting instead of doing it silently.
May 11, 2023 at 6:15 comment added Steve Barnes @AntonDuzenko - your C example is basically what the with statement does but with a lower overhead both processing wise and cognitively.
May 11, 2023 at 6:13 comment added Steve Barnes @wtr - I have added a couple of points to support (1)
May 11, 2023 at 6:10 history edited Steve Barnes CC BY-SA 4.0
Expanded some points.
May 10, 2023 at 9:28 comment added Anton Duzenko Why can't we call another function to detect stream end instead of catching an exception? while(!eof()) { readByte() } There is no justification for using exceptions for anything at all other than unexpected errors.
Mar 24, 2021 at 20:43 comment added RayLuo @wTyeRogers, your comment seems to boil down to: (1) "but I think the answer should be a yes" (2) "Since Steve Barnes did not provide arguments to support his 'No!' statement, I went on to downvote this answer". Hmm, now your comment also became an emphatic statement. wTyeRogers can you provide your answer with arguments to support "using exceptions for flow control is best practice in Python"?
Aug 22, 2019 at 16:23 comment added wtr Your answer seems to boil down to: A) "NO!" B) there are valid examples of where control flow via exceptions work better than alternatives C) a correction of the question's code to use generators (which use exceptions as control flow, and do so well). While your answer is generally informative, no arguments appear to exist in it to support item A, which, being in bold and seemingly the primary statement, I would expect some support for. If it were supported, I wouldn't downvote your answer. Alas...
Aug 22, 2019 at 16:21 comment added wtr Hey @SteveBarnes, the divide by zero error catch example sounds like poor programming (with a too-general catch that doesn't re-raise the exception).
Jan 26, 2019 at 8:55 comment added Steve Barnes @DanielWaltrip I see far too much code, in various programming languages, where exceptions are used, often far too widely, when a simple if would be better. When it comes to debugging & testing or even reasoning about your codes behavior it is better not to rely on exceptions - they should be the exception. I have seen, in production code, a calculation that returned via a throw/catch rather than a simple return this meant that when calculation hit a divide by zero error it returned a random value rather than crashing where the error happened this caused several hours of debugging.
Jan 25, 2019 at 23:20 comment added Daniel Waltrip You say: "NO! - not in general - exceptions are not considered good flow control practice with the exception of single class of code". Where is the rationale for this emphatic statement? This answer seems to focus narrowly on the iteration case. There are many other case where people might think to use exceptions. What is the problem with doing so in those other cases?
Jun 18, 2017 at 5:37 history edited Steve Barnes CC BY-SA 3.0
Change Found to Not Found
Jun 18, 2017 at 5:29 history answered Steve Barnes CC BY-SA 3.0