On Sep 26, 2019, at 02:07, salemalbr...@gmail.com wrote: > > 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. 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? _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/6YA45ZBUUO34AQ5FTSL3UYFLL7LDORGJ/ Code of Conduct: http://python.org/psf/codeofconduct/
