On 7 July 2017 at 22:23, Koos Zevenhoven <k7ho...@gmail.com> wrote:
> On Fri, Jul 7, 2017 at 7:28 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
>>
>>
>> As a result, our advice is to *avoid* trying to come up with systemic
>> fixes for structured exception handling, and instead focus on specific
>> use cases of "I want *this* exception type to have *that* attribute
>> for *these* reasons". Those kinds of proposals usually don't even rise
>> to the level of needing a PEP - they're just normal RFEs on the issue
>> tracker.
>>
>
> It would seem to make sense to try and 'standardize' how this is done for
> the cases where it is done at all. For example, there could be some kind of
> collection in the exceptions (not necessarily all exceptions) that contains
> all the objects that participated in the operation that led to the
> exception. Something consistent across the different exception types would
> be easier to learn.
Potentially, but that would just require a proposal for a new
created-on-first-access property on BaseException, rather than a
proposal to change the constructor to implicitly populate that
attribute from arbitrary keyword arguments.
The functional equivalent of:
@property
def details(self):
if "_details" in self.__dict__:
details = self._details
else:
details = self._details = dict()
return details
Given something like that, the preferred API for adding details to an
exception could be to do "exc.details[k] = v" rather than passing
arbitrary arguments to the constructor, which would avoid most of the
problems that afflicted the original "message" attribute concept.
Subclasses would also be free to override the property to do something
different (e.g. pre-populating the dictionary based on other exception
attributes)
So if folks want to explore this further, it's probably worth framing
the design question in terms of a few different audiences:
1. Folks writing sys.excepthook implementations wanting to provide
more useful detail to their users without overwhelming them with
irrelevant local variables and without having to customise the hook
for every structured exception type
2. Folks wanting to "make notes" on an exception before re-raising it
3. Folks writing new exception subclasses in Python and wanting to
provide structured exception details in a consistent way
4. Folks adapting existing structured exception subclasses in Python
to expose the new API
5. Folks adapting existing structured exception subclasses in C to
expose the new API
6. Folks raising structured exceptions for flow control purposes who'd
be annoyed by performance lost to unnecessary memory allocations
Any such proposal would also need to account for any existing
exception types that use "details" as the name of an ordinary instance
attribute and provide a suitable deprecation period.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
