Error handling toggle / levels
Hello, So when coding, at deferent stages we need different levels of error handling. For example at stage of finding the concept, initial implementation, alpha, releasing testing, etc. By some bits of code we can simulate enable/disable error handling. But it would be very helpful to have such thing built in the language with some more pythonic salt 😁. For example, Assume this behavior.. ************ SetExceptionLevel(50) try: x = 1 / 0 except(0) Exception as e: print(e) except (40) ZeroDivisionError as e1: x = math.inf except (40) ValueError as e2: x = None except(60) Exception as e3: raise e3 **************** i.e. one exception can have more than one handler and each handler has a level to enable it, so now for this example the first 2 exception will run only, If we want the last one to run also we need to change the first line to "SetExceptionLevel(70)" for example. The third one " ValueError " will never be triggered. And if no exception met the requirements "level and exception type" then the error will be raised out.
26.09.19 12:07, salemalbream@gmail.com пише:
It is not clear what your propose syntax means, but you can use e.g. such code: except (ZeroDivisionError if level > 40 or ()) as e1: x = math.inf If level > 0, you will catch ZeroDivisionError and set x = math.inf. If level <= 40 the ZeroDivisionError exception will pass to other handlers.
On Sep 26, 2019, at 02:07, salemalbream@gmail.com wrote:
What is this intended to do? You talk about different stages of development, but at what stage do you want 50 vs. 70 here, and why? Maybe this would be clearer with a better example. This one doesn’t seem to make much sense. And, even if it did, there’s only so much rationale you can usually get out of toy code. The first except handles all exceptions, so the others never run anyway, so why would you care about disabling or enabling them? And when would you ever want the first one? I can imagine wanting some function to return inf or None in the final code, but to raise in early testing so I can verify that it’s not happening along code paths where I wasn’t expecting it to happen. But I can’t imagine wanting to print the exception (and just the exception, not the traceback), and then continue on with the rest of the function, which will presumably raise an UnboundLocalError or, worse, use some previous and wrong value for x and now I won’t know why because I hid the traceback that would have told me what happened. Also, why isn’t the third one ever enabled? 40 < 50 (or 40 <= 50? I don’t know which you intend). So… is there some additional rule that when two exception handlers have the same level only the first one is ever enabled? If so, why? It’s pretty common to want to handle two different errors differently; that’s why the syntax allows multiple except clauses in the first place. If that’s not the rule, then what is? Meanwhile, what is the ValueError supposed to catch in 1/0? And finally, what’s the point of enabling the last one? Handling an exception by just reraising it (and doing it explicitly as raise e3 rather than just raise) means you get the same effect as with leaving it disabled, but less efficiently and less friendly to debugging?
It looks like Serhiy answered your main question, but I wanted to mention that rather than simply printing the exception, you could also print the full traceback using the "traceback" module:
Whereas with simply using `print(e)` you only get: division by zero The former is far more useful and gives you all of the information from the last exception without raising it. I'd recommend looking further into the traceback module if you'd like more customization, but using traceback.print_exc() is a substantial improvement by itself. On Thu, Sep 26, 2019 at 8:40 AM <salemalbream@gmail.com> wrote:
26.09.19 12:07, salemalbream@gmail.com пише:
It is not clear what your propose syntax means, but you can use e.g. such code: except (ZeroDivisionError if level > 40 or ()) as e1: x = math.inf If level > 0, you will catch ZeroDivisionError and set x = math.inf. If level <= 40 the ZeroDivisionError exception will pass to other handlers.
On Sep 26, 2019, at 02:07, salemalbream@gmail.com wrote:
What is this intended to do? You talk about different stages of development, but at what stage do you want 50 vs. 70 here, and why? Maybe this would be clearer with a better example. This one doesn’t seem to make much sense. And, even if it did, there’s only so much rationale you can usually get out of toy code. The first except handles all exceptions, so the others never run anyway, so why would you care about disabling or enabling them? And when would you ever want the first one? I can imagine wanting some function to return inf or None in the final code, but to raise in early testing so I can verify that it’s not happening along code paths where I wasn’t expecting it to happen. But I can’t imagine wanting to print the exception (and just the exception, not the traceback), and then continue on with the rest of the function, which will presumably raise an UnboundLocalError or, worse, use some previous and wrong value for x and now I won’t know why because I hid the traceback that would have told me what happened. Also, why isn’t the third one ever enabled? 40 < 50 (or 40 <= 50? I don’t know which you intend). So… is there some additional rule that when two exception handlers have the same level only the first one is ever enabled? If so, why? It’s pretty common to want to handle two different errors differently; that’s why the syntax allows multiple except clauses in the first place. If that’s not the rule, then what is? Meanwhile, what is the ValueError supposed to catch in 1/0? And finally, what’s the point of enabling the last one? Handling an exception by just reraising it (and doing it explicitly as raise e3 rather than just raise) means you get the same effect as with leaving it disabled, but less efficiently and less friendly to debugging?
It looks like Serhiy answered your main question, but I wanted to mention that rather than simply printing the exception, you could also print the full traceback using the "traceback" module:
Whereas with simply using `print(e)` you only get: division by zero The former is far more useful and gives you all of the information from the last exception without raising it. I'd recommend looking further into the traceback module if you'd like more customization, but using traceback.print_exc() is a substantial improvement by itself. On Thu, Sep 26, 2019 at 8:40 AM <salemalbream@gmail.com> wrote:
participants (5)
-
Andrew Barnert -
Ilya Kulakov -
Kyle Stanley -
salemalbream＠gmail.com -
Serhiy Storchaka