On Wed, Sep 29, 2021 at 10:01:52PM -0300, Soni L. wrote:
So uh, this is a hardly at all fleshed out idea, but one thing we really don't like about python is having to do stuff like this so as to not swallow exceptions:
Is that the Royal We or are you actually speaking on behalf of other people?
def a_potentially_recursive_function(some, args): """ Does stuff and things. Raises ExceptionWeCareAbout under so and so conditions. """ try: some.user_code() except ExceptionWeCareAbout as exc: raise RuntimeError from exc code_we_assume_is_safe() if args.something and some_condition: raise ExceptionWeCareAbout
I don't see an obvious recursive call there, although I suppose it could be buried in some.user_code(). It isn't clear to me why it matters that this could be recursive, or why you raise RuntimeError. By the way, you may not need the "raise...from exc" syntax. The difference between: except NameError: raise RuntimeError and except NameError as exc: raise RuntimeError from exc is *extremely* minimal. In a practical sense, the main difference is that the first traceback will say: NameError traceback During handling of the above exception, another exception occurred RuntimeError traceback and the second will say: NameError traceback The above exception was the direct cause of the following exception RuntimeError traceback So it might not matter that much to you. Anyway, that's just a minor aside.
It'd be nice if there was a way to... make this easier to deal with.
It isn't clear to me what part of the above isn't already easy to deal with. Maybe you need a more realistic, runnable, example that demonstrates why this is an actual problem? And maybe the actual problem is not exception handling, but a sub-optimal design for your algorithm. (More comments to follow.) -- Steve