Avoiding the Use of Exceptions in Python and Considering Alternatives

[waterflier]

I would like to propose a change in our error handling approach in Python. Please refrain from creating new exceptions (i.e., using the raise statement).

In languages where it is not possible to declare what exceptions a function might throw, the use of exceptions should be avoided. Otherwise, there's always a risk of uncaught exceptions. Wrapping each function call with try{}, can make the code structure unpleasantly complex.

In fact, exceptions should not be used as a regular error-handling mechanism. 90% of exceptions should lead to a program stop and facilitate easy debugging.

I appreciate the design of Result in Rust. Perhaps we can build a similar facility in Python. In the meantime, using traditional error code logic (0 for success, non-zero for errors) or True/False logic would make our code more readable and stable.

I look forward to hearing your thoughts on this proposal.

[wugren]

Exceptions seem to be the accepted error handling method in Python. All third-party libraries I have seen use exceptions. The advantage of exceptions is that users only focus on the errors they care about, and errors that they don't care about are thrown directly upward. Okay, this is similar to rust. If a python exception is not handled, it will crash the program, but it will output the call stack information of the error. This is easier to locate than rust.

If the return value method is used, countless codes for handling error values ​​must be written in all codes. Most of these codes simply return error values ​​upwards and do not add special error handling logic, but each call All must be written. It is very uncomfortable to write this way and it is easy to forget. The problems caused by this method may be more difficult to deal with. I don’t think it is a good method.

[waterflier]

While I don't object to the correct use of exception handling, it's unfortunate that most third-party libraries do not use exceptions correctly, particularly when distinguishing between errors and exceptions. Errors are predictable and occur under normal circumstances, while exceptions are unusual. For parsing libraries and network libraries, format errors and network issues should be anticipated and handled as errors rather than exceptions.

Using exceptions in Python is fine if we're scripting, but if we're planning to build 24*7 services with Python, it would be unwise to have those services stupid interrupted by what should be errors treated as exceptions.

What I hope for us is to avoid making the same mistakes. We should not use exceptions as a substitute for error handling. For third-party libraries, we need to carefully discern which exceptions are errors that we need to catch correctly, and which are standard exceptions that should lead to a crash.

Let's ensure our code is robust and resilient by treating errors and exceptions appropriately.