I think the main issue is this: exception handling is already problematic with its nonlocal transfer of control. Making it bidirectional makes code even more difficult to understand. State will change "under your feet" without any syntactic clue.
On 1/6/19 9:54 PM, simon.bordeyne wrote:
> I knew that you can just chain try/except blocks, and it's how I do it
> now, but the example I provided wasn't very realistic.
> Take for example the initialization of a class from a config file,
> config file which may or may not have certain keys in it. With many
> keys, it is very inconvenient to chain try/except blocks to handle
> every possible case. Having the continue keyword would prove useful to
> put several error prone lines of code into a single try block, and
> have the execution continue as normal at tge statement after the
> statement errored out
For something like reading options from a config file, I would use a
call that specifies the key and a value to use if the key isn't present,
and inside that function I might use a try to handle any exception
caused when processing the key, and it could return the default.
For your case, it is hard to imagine what you could put in the except
block to handle the error, as you have no idea which key threw the
error, so you have no idea which key needs to be fixed.
Also, what happens if the exception is thrown inside a function that is
called, do you return to the next line of that function, or the next
line after the function call?
What happens if the exception happens inside a loop (that is inside the
try)? Do you just go to the next instruction in the loop and continue
Python-ideas mailing list
Code of Conduct: http://python.org/psf/codeofconduct/