Sorry Stephen (and Steven). I'll do better next time.
The way I see it there are two problems, and the second causes the first.
The first problem is that there is no direct access to the components that make
up the error in some of the standard Python exceptions.
>>> foo
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'foo' is not defined
If you need access to the name, you must de-construct the error message. To get
direct access to the name, it would need to be passed to the exception when
raised. Why wasn't that done? That leads us to the second problem: the base
exception does not handle arguments gracefully unless you only pass an error
message all by itself. For example:
>>> try:
>>> name = 'foo'
>>> raise NameError('%s: name is not defined.' % name)
>>> except NameError as e:
>>> print(str(e))
foo: name is not defined.
Here, printing the exception cast to a string produces a reasonable error
message.
>>> try:
>>> name = 'foo'
>>> raise NameError(name, '%s: name is not defined.' % name)
>>> except NameError as e:
>>> print(str(e))
('foo', 'foo: name is not defined.')
In this case, printing the exception cast to a string does not result in a
reasonable error message.
So the basic point is that the lack of reasonable behavior for str(e) when
passing multiple arguments encourages encapsulating everything into an error
message, which makes it difficult to do many useful things when handling the
exceptions.
Steven seems to object to the fact that the proposal takes arbitrary keyword
arguments. I think this is the point of the 'nym' example. But in fact that is
not really the point of the proposal, it is just a minor design choice.
Instead, Steven recommends creating a custom exception with explicitly declared
named arguments. And I agree with him that that is the right thing to do in
many cases. But sometimes you just want something quick that you can use that
does not require you to define your own exception. And sometimes, even though
people should define custom exceptions, they don't. For example, NameError,
KeyError, IndexError, ...
-Jeff
_______________________________________________
Python-ideas mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
