On 2020-04-11 8:39 p.m., Dominik Vilsmeier wrote:

If I understand correctly, you want a way for distinguishing between exceptions that were explicitly and intentionally `raise`'ed as part of an API and exceptions that were unintentionally raised due to bugs. So for example:

    raise ValueError(f'Illegal value for xyz: {xyz}')  # part of the API
    foo['bug']  # this should have been 'bag' so it's a bug

In addition to that, the user of the API should be able to decide whether they let the API raise in their *exception space* or not.

I think you could realize this in today's Python by using `raise ... from espace` where espace is an instance of a custom exception and then check the resulting exception's `__cause__`. So for example:

    class ESpace(Exception):
        pass

    # I'm the user of an API and I want to distinguish their API errors from bugs.
    espace = ESpace()
    try:
        api_func(espace=espace)
    except KeyError as err:
        if err.__cause__ is espace:  # it's part of the API
            pass
        else:  # it's a bug
            pass

And the API functions would have to raise their exceptions explicitly from the provided `espace`:

    def api_func(espace=None):
        raise KeyError() from espace  # part of the API; sets the exception's __cause__ to `espace`
        foo['bug']  # here __cause__ will be None, just like if no `espace` had been provided

It's probably an abuse of the exception mechanism and also relies on a dunder, but for your own projects it could serve the purpose.


I figured something better instead. you can have a class ESpace, but you use it like so:

    espace = ESpace()

    try:
        foo(espace=espace)
    except espace.module.submodule.Exception:
        ...

e.g. for builtins:

    espace = ESpace()

    try:
        raise espace.ValueError
    except espace.ValueError:
        ...

and it dynamically creates subclasses of whatever you give it. I'm not sure how doable this is in current python, but it's super close to what I want. so hey if it works well, we can promote it to the stdlib? just need to encourage ppl not to check the type of their espace argument so you can silently swap the external one for the stdlib one and nothing breaks.

(still need a better way to pass it into operators but eh)


On 11.04.20 18:07, Soni L. wrote:
the reason I'm proposing this is that I like standard exception types having well-defined semantics. this "special, very fragile, syntax for the same purpose" doesn't take away from that, and instead just adds to it.

it's a way of having multiple, independent, "local" dynamic scopes. instead of just one global dynamic scope. and enables you to freely use standard exception types.

if anything it's closer to passing in a namespace with a bunch of standard exception types every time you wanna do stuff. which... I could also get behind tbh. an stdlib addition that dynamically exposes subclasses of the standard exception types, unique to that namespace instance. would still need some way of passing it in to operators and stuff tho.

_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@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/HAT3Y77ONNJ5VKOFH6ZPFQ3LZXEQB2Q4/
Code of Conduct: http://python.org/psf/codeofconduct/

_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@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/X7YXXEBILZNA52UUDN7PC4R6RHVAIXGO/
Code of Conduct: http://python.org/psf/codeofconduct/