René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Introducing try..catch","articleBody":"*If* we find we really need new syntax to flag that people have thought about the consequences of multi-exceptions, we could switch the existing `try..except` syntax to `try..catch`. It seems most other languages use the latter keyword anyway.\r\n\r\nSyntax\r\n-------\r\n\r\nThe syntax would just replace `except` with `catch`, leaving everything else the same.\r\n\r\nWe have the option however of disallowing `catch:` (i.e. with no exception, the catch-all block) -- forcing people (and automatic translators) to write `catch BaseException:`.\r\n\r\nNote that `catch` would have to be a soft keyword (supported by the new PEG parser, see PEP 617), since there are plenty of other uses of `catch` in existing code that we don't want to break.\r\n\r\nTransition\r\n----------\r\n\r\nThe transition plan would be that `try..exept` will eventually be removed from the language. There would be three stages:\r\n\r\n1. `try..catch` and `try..except` can both be used.\r\n2. `try..except` works but gives a deprecation warning.\r\n3. `try..except` stops working.\r\n\r\nPossibly stage 2 can be split and `try..except` inside `async` functions can be deprecated sooner than in other contexts.\r\n\r\nDuring stages 1 and 2, each `try` statement must use either `catch` or `except` -- you cannot have both `catch` and `except` blocks in the same statement. (But you can have them in the same file.)\r\n\r\nSemantics\r\n-----------\r\n\r\nWhen the raised exception is not a multi-exception the semantics of `try..catch` is the same as for `try..except`.\r\n\r\nWhen the raised exception is a multi-error the semantics change.\r\n\r\nBasically when a multi-error contains different exception types it is possible that more than one `catch` block runs. E.g.\r\n```\r\ntry:\r\n    raise MultiError([ValueError(), ZeroDivisionError(), RuntimeError()])  # or whatever\r\ncatch ValueError:\r\n    print(\"VE\")\r\ncatch RuntimeError:\r\n    print(\"RE\")\r\n```\r\nwould print \"VE\" and \"RE\" and then raise (bubble up) `RuntimeError()` (or `MultiError([RuntimeError()]`).\r\n\r\nIf there's an `else` block it only gets run if no exceptions were raised in the first place.\r\n\r\nIf there's a `finally` block it gets run after all `catch` blocks (if any) have run, before bubbling up the unhandled exceptions (if any).\r\n\r\nThe order in which the exceptions in the multi-error are handled is just the order in which the `MultiError` object regurgitates them.\r\n\r\nMultiple exceptions of the same type\r\n-------------------------------------\r\n\r\nThis is an open issue.\r\n\r\nWhat if the try block raises `MultiError([ValueError(\"A\"), ValueError(\"B\")])`? We could define different semantics.\r\n\r\nNote that there would also be a question about two different exception classes that derive from the same base class, where the `catch` class specifies that base (or ultimately `catch BaseException`). So we cannot rely on `MultiError` to split exceptions based on class before we start matching exceptions to catch blocks.\r\n\r\n**TO BE CONTINUED IN A LATER COMMENT** (I deleted some meta-comments related to this.)","author":{"url":"https://github.com/gvanrossum","@type":"Person","name":"gvanrossum"},"datePublished":"2020-10-22T18:22:27.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":43},"url":"https://github.com/3/exceptiongroups/issues/3"}