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.


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-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/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-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/X7YXXEBILZNA52UUDN7PC4R6RHVAIXGO/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to