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/

Reply via email to