3 ms·

Nobody seems to have touched on this so I'll go. Since trying rust's ans zig's error system I have avoided using python exception and replaced them with [1]. B

Nobody seems to have touched on this so I'll go. Since trying rust's ans zig's error system I have avoided using python exception and replaced them with [1]. Basically functions return Ok(value) or Err(msg). callers can then get the result with `a = fn(a,b).unroll()`. For Ok it will unwrap and for Err it will return early (with a decorator to catch the virtual exception). The only overhead is the decorator, apart from this the ergonomics are the same as rust. It's so nice I hope it becomes a part of the language some day. [1] https://pypi.org/project/result/ https://pypi.org/project/result/

stavros 5y ago
That's nice, thanks for reminding me of this. I will use it for a project, as I, too, very much like the way Rust does error handling.
jbritton 5y ago
I have done (ok, result) returns in some python code. At some point though, I realized almost any line of python can raise an exception. I find that there is just too much friction trying to avoid the exception system. I just learned to embrace it. Where exceptions are problematic for my code base is when unwinding the stack is not the best behavior. Sometimes, I want the following lines to execute and sometimes I want to retry. Exceptions make a default execution flow very easy, but the default is sometimes wrong, and the correct flow is not considered until undesirable behavior appears at runtime. An (ok, result) system seems like it might force one to think more carefully about the proper flow. But the price is always having to think about it, when stack unwinding is usually the right flow. Or one might be tempted to create a Haskell like monad that automatically skips execution of following expressions, leading to the same bugs as an exception system. Correct code is possible with either system. I’m undecided if one system is more likely to lead to correct code.
sam_bristow 5y ago
That's an interesting experiment, but exceptions are pretty central to how Python works. For example, `for` loops are implemented by throwing a `StopIteration` exception when they're finished.
- jackhalford 5y ago
  I'm fine with exception being under the hood. It's just in actual app code I find the non locality of the flow makes things very implicit. I like explicit code.

stavros 5y ago

That's nice, thanks for reminding me of this. I will use it for a project, as I, too, very much like the way Rust does error handling.

jbritton 5y ago

I have done (ok, result) returns in some python code. At some point though, I realized almost any line of python can raise an exception. I find that there is just too much friction trying to avoid the exception system. I just learned to embrace it. Where exceptions are problematic for my code base is when unwinding the stack is not the best behavior. Sometimes, I want the following lines to execute and sometimes I want to retry. Exceptions make a default execution flow very easy, but the default is sometimes wrong, and the correct flow is not considered until undesirable behavior appears at runtime. An (ok, result) system seems like it might force one to think more carefully about the proper flow. But the price is always having to think about it, when stack unwinding is usually the right flow. Or one might be tempted to create a Haskell like monad that automatically skips execution of following expressions, leading to the same bugs as an exception system. Correct code is possible with either system. I’m undecided if one system is more likely to lead to correct code.

sam_bristow 5y ago

That's an interesting experiment, but exceptions are pretty central to how Python works. For example, `for` loops are implemented by throwing a `StopIteration` exception when they're finished.

jackhalford 5y ago
I'm fine with exception being under the hood. It's just in actual app code I find the non locality of the flow makes things very implicit. I like explicit code.