4 ms·

Your solution only works if it's the end of the program. Sometimes you need to exit conditionally. if foo: exit(0) more_code()

• tomp 7y ago
  IMO that's anti-pattern / code smell, in most situations.
  • ainiriand 7y ago
    You are right, as for example the tests would behave in an erratic way. It should be allowed to complete.
  • aepiepaey 7y ago
    As long as we're talking about libraries, yes. For cli tools, on the other hand, there are definitely legitimate cases for exiting early.
    • tomp 7y ago
      Sure, but even in most of those scenarios, I’d prefer to structure the code differently... perhaps write a main() function that just returns, or other functions... more modular, maintainable, teatable, ... admittedly, in Python you need to use os.exit if you want to return a specific non-zero exit code, but even in that case good code style would be something like def main() blablabla if foo: return bar ... return 8 if __name__ == “__main__”: os.exit(main()) Of course that’s just my advice / opinion / preference, other ways are valid as well...
• aepiepaey 7y ago
  And in that case, raise SystemExit(code) is nicer (and does not require an an import).
  • capableweb 7y ago
    Isn't raise for "throwing" exceptions/errors though? `raise SystemExit(code)` would imply an error, but if `code` is 0, the OS wouldn't consider it an error but an human looking at it would (correctly?) assume it's a error.
    • ORioN63 7y ago
      TIL SystemExit and that `sys.exit` actually raises SystemExit. From Python docs: https://docs.python.org/3/library/exceptions.html#SystemExit https://docs.python.org/3/library/exceptions.html#SystemExit > exception SystemExit > This exception is raised by the sys.exit() function. It inherits from BaseException instead of Exception so that it is not accidentally caught by code that catches Exception. This allows the exception to properly propagate up and cause the interpreter to exit. When it is not handled, the Python interpreter exits; no stack traceback is printed. The constructor accepts the same optional argument passed to sys.exit(). If the value is an integer, it specifies the system exit status (passed to C’s exit() function); if it is None, the exit status is zero; if it has another type (such as a string), the object’s value is printed and the exit status is one. > A call to sys.exit() is translated into an exception so that clean-up handlers (finally clauses of try statements) can be executed, and so that a debugger can execute a script without running the risk of losing control. The os._exit() function can be used if it is absolutely positively necessary to exit immediately (for example, in the child process after a call to os.fork()). Replying to your comment regarding: > Isn't raise for "throwing" exceptions/errors though? Well, some would argue that is idiomatic in python. A quick google search not only autocompletes "exceptions for control flow" to "exceptions for control flow python", but on the second search, most results discuss that (with many agreeing). I guess you can say most python developer wouldn't immediately assume it's an error. I definitely can say, I don't.
      • hathawsh 7y ago
        Right. In Python, raising an exception is considered just as safe and normal as returning a value, so Python uses exceptions even for very common things like stopping iterations. IMHO a Python exception is quite similar to a Rust "Result::Err".